3 ms·

> all functions have unique distinct names > To avoid all mental anguish when I need a small function that should be somewhere else and isn't I stick it in a m

> all functions have unique distinct names > To avoid all mental anguish when I need a small function that should be somewhere else and isn't I stick it in a module elib1_misc.erl. I can totally relate. It doesn't reduce collisions significantly if a function is named Foo::Bar() instead of Foo_Bar(). But the latter has the advantage that we are free to move the function (avoiding initial decision paralysis, and later it's easier to clean up) and being required to reference this function with fully qualified name leads to much more readable code (IMO). What I've been doing lately is I just make descriptive function names. I don't even use a prefix, but may still include type names in the function name. Example, slightly long name: copy_from_StreamsChain_to_Textnode(). That's totally fine in terms of avoiding (the FUD concerning) collisions and it flows very naturally. Just like with Objects/methods, not doing namespaces leads to a significant reduction in decision paralysis (time consuming taxonomic concerns - "where should I put...?") for me.

pjc50 7y ago
The converse question to "where should I put" is "where could I find". Namespaces and objects make it easier to find related functionality so you don't have to reinvent it. Without good techniques for locating relevant useful functions, you're just writing write-only code. And the technique of "if I was going to write this, where would I put it" doesn't even work when I'm trying to find my keys, let alone among all the developers of the world.
- jstimpfle 7y ago
  That's an interesting thought. But consider - If "where should I put" is unclear, "where should I find" is equally unclear. - Code should be mostly "local" anyway (what's the word again?) - Text search exists, and IDEs nowadays even do fuzzy search. - I didn't say we should make a total mess. If there is an obvious organizational strategy, just go for it! But namespaces are not that important; you can still get most of the organizational advantages of namespaces by just grouping in files and maybe prefixing.
- Oreb 7y ago
  “Where could I find” is indeed an important question, but it is not obvious to me that hierarchical namespaces are the best solution. Couldn’t something like a list of tags attached to every function/type/whatever be at least as effective?
  - alexisread 7y ago
    I think the end result of something like this is call-by-meaning. Alan Kay and co. Have published several papers on this subject, but in a nutshell the code looks for a matching function to a signature and return type, then calls it. Obv. There are issues with this approach if fully automatic (how many sum functions take two ints and return int?) but there's no reason why we can't use a sig/return to filter on ie. The same function can be in 2 modules if filtering by sig or by return type. With typing similar to Haskell we can be even more strict - the sig/return is a contract, and we can have multiple types like userInputInt, randomInt which can differentiate similar inputs. With good typing and behavioural provability we may be able to move towards a call-by-meaning system

pjc50 7y ago

The converse question to "where should I put" is "where could I find". Namespaces and objects make it easier to find related functionality so you don't have to reinvent it. Without good techniques for locating relevant useful functions, you're just writing write-only code. And the technique of "if I was going to write this, where would I put it" doesn't even work when I'm trying to find my keys, let alone among all the developers of the world.

jstimpfle 7y ago
That's an interesting thought. But consider - If "where should I put" is unclear, "where should I find" is equally unclear. - Code should be mostly "local" anyway (what's the word again?) - Text search exists, and IDEs nowadays even do fuzzy search. - I didn't say we should make a total mess. If there is an obvious organizational strategy, just go for it! But namespaces are not that important; you can still get most of the organizational advantages of namespaces by just grouping in files and maybe prefixing.
Oreb 7y ago
“Where could I find” is indeed an important question, but it is not obvious to me that hierarchical namespaces are the best solution. Couldn’t something like a list of tags attached to every function/type/whatever be at least as effective?
- alexisread 7y ago
  I think the end result of something like this is call-by-meaning. Alan Kay and co. Have published several papers on this subject, but in a nutshell the code looks for a matching function to a signature and return type, then calls it. Obv. There are issues with this approach if fully automatic (how many sum functions take two ints and return int?) but there's no reason why we can't use a sig/return to filter on ie. The same function can be in 2 modules if filtering by sig or by return type. With typing similar to Haskell we can be even more strict - the sig/return is a contract, and we can have multiple types like userInputInt, randomInt which can differentiate similar inputs. With good typing and behavioural provability we may be able to move towards a call-by-meaning system