7 ms·

I really like the idea of a no module system. If you look at the /usr/bin directory of a Linux system there aren't any namespaces. There's 1,000+ binaries thro

by nickjj 7y ago

I really like the idea of a no module system. If you look at the /usr/bin directory of a Linux system there aren't any namespaces. There's 1,000+ binaries thrown into 1 folder, each with a distinct name and things work nicely. Imagine if you tried to group those binaries into 1 or more folder driven namespaces. Where would things go? The amount of bike shedding would be endless and I don't think it would be a better solution in the end even if you managed to pull it off. All of Joe's points in that post are spot on.

dmitriid 7y ago
There are namespaces, you just don't see them. That's why there's python and python3, cmake and cmake2 (IIRC) etc. With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name.
- tosh 7y ago
  You could use something like uuids for naming functions and attach meta data (including e.g. human readable names and/or namespaces).
  - pjc50 7y ago
    > uuids for naming functions Microsoft COM would like a word. {20D04FE0-3AEA-1069-A2D8-08002B30309D}
    - ChrisSD 7y ago
      People on HN keep reinventing COM. I swear every other week we have discussions like the above in at least one thread.
      - pjc50 7y ago
        Yup. There's a lot of factors at play. We're a very ahistorical field; lots of folks are self-taught and therefore reinventing everything is normal to them; the dev universe is heavily siloed into "Web+UNIX" versus "Microsoft" versus some now moribund siloes (Websphere! Solaris! Alpha!); Microsoft have almost no community compared to the FLOSS world (although .net is changing this a bit); and finally the simple fact that COM and you and I are very, very old. I'm not even sure that reinventing COM would be a bad idea - you can definitely do some great things with it, and the specific implementation details of COM are crufty. But doing so deliberately rather than accidentally would be better, with a review of benefits and problems of COM approaches.
        pjmlp 7y ago
        COM has been reinvented, as UWP. :) As for the community, maybe not on SV, but there are plenty of Microsoft communities and meeting groups.
      - NikkiA 7y ago
        Tell them it's called 'Core Foundation Plugin' and point at the apple docs, they'll start loving it. https://developer.apple.com/documentation/corefoundation/cfplugin-rip https://developer.apple.com/documentation/corefoundation/cfp...
    - abstract7 7y ago
      It's "Component Object Model" for anyone out there that almost gave up after googling "COM".
- nickjj 7y ago
  > There are namespaces, you just don't see them. That's why there's python and python3, cmake and cmake2 (IIRC) etc. IMO python and python3 is a very welcome feature not a negative side effect of no namespaces. At call time it's super explicit so you know exactly what version you're using. But in most module driven programming languages you might import the foo function at the top of your file and then use foo in 5 different places within that file. However, you spend 99% of your time working with the code in the file not glancing at imports, so now you're left wondering not only where foo is coming from, but who provided foo. Is it from the standard library, your own code base or a third party author? Suddenly you need to keep all of this in your head and it sucks. Phoenix (a web framework for Elixir) has been taking steps to remove a lot of loose function imports so you know what module they are coming from at call time, but that's because Elixir as a language has modules. But even still, explicitness where you're using it is so much better in the long run for maintenance, even if it involves typing a few more characters.
  - Anonymous4C54D6 7y ago
    As way-too-often, I think the solution should be a good IDE. There is nothing stopping your IDE from completing "foo" as "module1.foo" and offering "module2.foo" as well if it exists. Alternatively the IDE could just display "module1.foo" instead of foo because that is what the import dictates. As always with dynamic things and editing code for them, this will be more difficult to get right when imports are dynamic.
- dkersten 7y ago
  > There are namespaces, you just don't see them. That's why there's python and python3, cmake and cmake2 (IIRC) etc. That's a versioning issue, that would happen with namespaces too. You'll have to disambiguate somehow and if a version number is the natural way, then that's the natural way regardless of if a single name or namespaced. Keeping the next incompatible version as a separate thing (eg python vs python3, instead of continuing python but with semvers saying that 3.0 breaks 2.x compatibility) is actually a good idea. It leads to fragmentation, sure, but it makes dealing with the different versions easier IMHO and incompatible versions may as well be totally different things anyway. > With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name. Yes, completely agree!
- lootsauce 7y ago
  Just spit-balling here... I think a proposal like this can benefit from making some assumptions about tooling, the database of functions and their metadata would logically be tightly integrated into your editor. The official name of the function could simply be a hash of its contents, the serialized ast then hashed could be another option for matching exactly-syntactically equivalent code. Then human friendly names could be automatically searchable and tacked on in the code via tooling which presents the metadata in-line but does not become part of the source.
jcelerier 7y ago
> and things work nicely. no they don't
cjfd 7y ago
Well, with 1000 names you still don't get (many) name collisions so no modules/namespaces is fine. At some point you will find yourself introducing smurf namespacing and then I would consider modules/namespaces the better solution.
- enriquto 7y ago
  If you think about it, smurf namespacing is much simpler thus more elegant than a "real" namespace system.
  - cjfd 7y ago
    In one sense, yes, but in another no. The main problem is that one can get real long names.
    - enriquto 7y ago
      Depending on your philosophy, that may be a feature to you. I tend to like this effect, because it forces the programmer to avoid building deeply nested structures, which is too easy to do when you abuse modules/namespaces.
      - cjfd 7y ago
        That is a valid point. There is a tendency for things to go the java way.
        goatlover 7y ago
        Because long names in Java meant avoiding deep nesting?
NikkiA 7y ago
quick, I have a linux box here that I use for some scheme and some CLR development, what does `csi` run ? chicken-scheme's interpreter or microsoft's C# repl ?
- tremon 7y ago
  Run `csi --help` and find out?
  - TeMPOraL 7y ago
    And hope it won't delete your working directory. Seriously though, considering the CLI software I use occasionally on my Linux machine, for any given program one - and only one - of the following will tell you its version: -v, -version, --version, version. I never can guess in advance which one is the right to use.
brightball 7y ago
I’m a big fan of Joe...but I also remember PHP before it had namespaces...and it was a train wreck. IMO all of the improvements in the PHP world have happened because they added them. I can see it for core libraries, but outside of that I think namespaces are necessary for the greater language ecosystem.
- nickjj 7y ago
  I was there in the PHP 4.x days too during the early 2000s, and you know, I really liked it. It just made things so simple to understand and work with. Look up a function, see a bunch of examples in the docs and use it right away without having to worry about imports and lugging around a ton of baggage. I think the main reason PHP got such a bad rap for flat functions is because they implemented it poorly. So many things were extremely inconsistent when it came to naming conventions and argument orders that it became near impossible to remember them in a systematic way. But couldn't that problem be addressed today since we're aware that naming consistency is an important programming language feature? > I can see it for core libraries, but outside of that I think namespaces are necessary for the greater language ecosystem. Yeah I could get on board with that. Docker sort of does this now with Docker images. At the UI level (the tooling we use in our day to day like the CLI) we don't need to access "elixir" or "python" images with a namespace (Docker adds it for us automatically), but we are free to create our own brightball/elixir or nickjj/elixir images to avoid conflicts. But in a programming world, I would like to type brightball_elixir at call time in my code instead of importing elixir from brightball, because with the latter I have no idea if elixir is coming from you, me, or the standard library unless I move away from the code and look at the import.
  - brightball 7y ago
    I'm mainly talking about the framework world at that time. They all reinvented EVERYTHING because they couldn't just easily include a shared database library, templating library, etc. They all reproduced their own with their own names to get around it. That type of stuff. The core language was about the same regardless, but the ecosystem improved dramatically.
coldtea 7y ago
>If you look at the /usr/bin directory of a Linux system there aren't any namespaces. There's 1,000+ binaries thrown into 1 folder, each with a distinct name and things work nicely. That's the last example of a nice design I would bring, and the worst possibly argument in favor of no modules/namespacing. A flat /usr/bin/... with 1000+ binaries in UNIX is a bad solution we ended up with because back in the day where UNIX was created there were just a few dozens of binaries, so it was "good enough".
- coding123 7y ago
  This was the hardest thing to get used to in linux coming from Windows. In Windows an installed program lives in Program Files and has a shortcut that starts it from it's home folder. That's very different from a namespace collision possible global install that can be run from any folder. I still don't fully agree with it but it makes some things easier. The Windows way also made multiple version installs possible.
  - dragonwriter 7y ago
    > In Windows an installed program lives in Program Files and has a shortcut that starts it from it's home folder. And command line tools have that folder added to the PATH, and Windows has a real and ongoing problem with PATH getting too long for the OS to handle when you have enough of them. Windows is GUI optimized with shell as an afterthought, Linux is vice versa.
  - Crinus 7y ago
    FWIW you get the same on Linux by installing stuff in /usr/whatever/wherever, /usr/local/whatever/wherever or /opt (which is the closest to Program Files-like place) and making symlinks to the "global" binaries (those meant to be accessible via the shell) while keeping everything else in the application-specific folder. It isn't very uncommon to see binaries inside /usr/bin being symlinks to binaries in other directories, even if you stick with distribution-only packages.
  - cmcaine 7y ago
    You can have multiple versions of a program installed in linux. Most package managers won't help you very much with that, but it's about as easy as windows if the programs are interpreted or statically linked or compile easily with your system libraries. NixOS and distri are notable package managers that do make installing different versions of packages pretty easy.
mrighele 7y ago
But a unix system has a module system: the filesystem and its folders. The fact that there are a number of "functions" that are in the same "default namespace" is just a convenience: if needed two binaries with the same name can coexist. Also i will add that in fact the systen binaries are already split: at minimum /usr/bin and /usr/sbin (but also historically, /bin and /sbin although i think in recent linux system the last two are just symlinks to the formers, or the other way around)
ggg3 7y ago
it is also what php did initially :)

by nickjj 7y ago

dmitriid 7y ago

There are namespaces, you just don't see them. That's why there's python and python3, cmake and cmake2 (IIRC) etc. With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name.

tosh 7y ago
You could use something like uuids for naming functions and attach meta data (including e.g. human readable names and/or namespaces).
- pjc50 7y ago
  > uuids for naming functions Microsoft COM would like a word. {20D04FE0-3AEA-1069-A2D8-08002B30309D}
  - ChrisSD 7y ago
    People on HN keep reinventing COM. I swear every other week we have discussions like the above in at least one thread.
    - pjc50 7y ago
      Yup. There's a lot of factors at play. We're a very ahistorical field; lots of folks are self-taught and therefore reinventing everything is normal to them; the dev universe is heavily siloed into "Web+UNIX" versus "Microsoft" versus some now moribund siloes (Websphere! Solaris! Alpha!); Microsoft have almost no community compared to the FLOSS world (although .net is changing this a bit); and finally the simple fact that COM and you and I are very, very old. I'm not even sure that reinventing COM would be a bad idea - you can definitely do some great things with it, and the specific implementation details of COM are crufty. But doing so deliberately rather than accidentally would be better, with a review of benefits and problems of COM approaches.
      - pjmlp 7y ago
        COM has been reinvented, as UWP. :) As for the community, maybe not on SV, but there are plenty of Microsoft communities and meeting groups.
    - NikkiA 7y ago
      Tell them it's called 'Core Foundation Plugin' and point at the apple docs, they'll start loving it. https://developer.apple.com/documentation/corefoundation/cfplugin-rip https://developer.apple.com/documentation/corefoundation/cfp...
  - abstract7 7y ago
    It's "Component Object Model" for anyone out there that almost gave up after googling "COM".
nickjj 7y ago
> There are namespaces, you just don't see them. That's why there's python and python3, cmake and cmake2 (IIRC) etc. IMO python and python3 is a very welcome feature not a negative side effect of no namespaces. At call time it's super explicit so you know exactly what version you're using. But in most module driven programming languages you might import the foo function at the top of your file and then use foo in 5 different places within that file. However, you spend 99% of your time working with the code in the file not glancing at imports, so now you're left wondering not only where foo is coming from, but who provided foo. Is it from the standard library, your own code base or a third party author? Suddenly you need to keep all of this in your head and it sucks. Phoenix (a web framework for Elixir) has been taking steps to remove a lot of loose function imports so you know what module they are coming from at call time, but that's because Elixir as a language has modules. But even still, explicitness where you're using it is so much better in the long run for maintenance, even if it involves typing a few more characters.
- Anonymous4C54D6 7y ago
  As way-too-often, I think the solution should be a good IDE. There is nothing stopping your IDE from completing "foo" as "module1.foo" and offering "module2.foo" as well if it exists. Alternatively the IDE could just display "module1.foo" instead of foo because that is what the import dictates. As always with dynamic things and editing code for them, this will be more difficult to get right when imports are dynamic.
dkersten 7y ago
> There are namespaces, you just don't see them. That's why there's python and python3, cmake and cmake2 (IIRC) etc. That's a versioning issue, that would happen with namespaces too. You'll have to disambiguate somehow and if a version number is the natural way, then that's the natural way regardless of if a single name or namespaced. Keeping the next incompatible version as a separate thing (eg python vs python3, instead of continuing python but with semvers saying that 3.0 breaks 2.x compatibility) is actually a good idea. It leads to fragmentation, sure, but it makes dealing with the different versions easier IMHO and incompatible versions may as well be totally different things anyway. > With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name. Yes, completely agree!
lootsauce 7y ago
Just spit-balling here... I think a proposal like this can benefit from making some assumptions about tooling, the database of functions and their metadata would logically be tightly integrated into your editor. The official name of the function could simply be a hash of its contents, the serialized ast then hashed could be another option for matching exactly-syntactically equivalent code. Then human friendly names could be automatically searchable and tacked on in the code via tooling which presents the metadata in-line but does not become part of the source.

jcelerier 7y ago

> and things work nicely. no they don't

cjfd 7y ago

Well, with 1000 names you still don't get (many) name collisions so no modules/namespaces is fine. At some point you will find yourself introducing smurf namespacing and then I would consider modules/namespaces the better solution.

enriquto 7y ago
If you think about it, smurf namespacing is much simpler thus more elegant than a "real" namespace system.
- cjfd 7y ago
  In one sense, yes, but in another no. The main problem is that one can get real long names.
  - enriquto 7y ago
    Depending on your philosophy, that may be a feature to you. I tend to like this effect, because it forces the programmer to avoid building deeply nested structures, which is too easy to do when you abuse modules/namespaces.
    - cjfd 7y ago
      That is a valid point. There is a tendency for things to go the java way.
      - goatlover 7y ago
        Because long names in Java meant avoiding deep nesting?

NikkiA 7y ago

quick, I have a linux box here that I use for some scheme and some CLR development, what does `csi` run ? chicken-scheme's interpreter or microsoft's C# repl ?

tremon 7y ago
Run `csi --help` and find out?
- TeMPOraL 7y ago
  And hope it won't delete your working directory. Seriously though, considering the CLI software I use occasionally on my Linux machine, for any given program one - and only one - of the following will tell you its version: -v, -version, --version, version. I never can guess in advance which one is the right to use.

brightball 7y ago

I’m a big fan of Joe...but I also remember PHP before it had namespaces...and it was a train wreck. IMO all of the improvements in the PHP world have happened because they added them. I can see it for core libraries, but outside of that I think namespaces are necessary for the greater language ecosystem.

nickjj 7y ago
I was there in the PHP 4.x days too during the early 2000s, and you know, I really liked it. It just made things so simple to understand and work with. Look up a function, see a bunch of examples in the docs and use it right away without having to worry about imports and lugging around a ton of baggage. I think the main reason PHP got such a bad rap for flat functions is because they implemented it poorly. So many things were extremely inconsistent when it came to naming conventions and argument orders that it became near impossible to remember them in a systematic way. But couldn't that problem be addressed today since we're aware that naming consistency is an important programming language feature? > I can see it for core libraries, but outside of that I think namespaces are necessary for the greater language ecosystem. Yeah I could get on board with that. Docker sort of does this now with Docker images. At the UI level (the tooling we use in our day to day like the CLI) we don't need to access "elixir" or "python" images with a namespace (Docker adds it for us automatically), but we are free to create our own brightball/elixir or nickjj/elixir images to avoid conflicts. But in a programming world, I would like to type brightball_elixir at call time in my code instead of importing elixir from brightball, because with the latter I have no idea if elixir is coming from you, me, or the standard library unless I move away from the code and look at the import.
- brightball 7y ago
  I'm mainly talking about the framework world at that time. They all reinvented EVERYTHING because they couldn't just easily include a shared database library, templating library, etc. They all reproduced their own with their own names to get around it. That type of stuff. The core language was about the same regardless, but the ecosystem improved dramatically.

coldtea 7y ago

>If you look at the /usr/bin directory of a Linux system there aren't any namespaces. There's 1,000+ binaries thrown into 1 folder, each with a distinct name and things work nicely. That's the last example of a nice design I would bring, and the worst possibly argument in favor of no modules/namespacing. A flat /usr/bin/... with 1000+ binaries in UNIX is a bad solution we ended up with because back in the day where UNIX was created there were just a few dozens of binaries, so it was "good enough".

coding123 7y ago
This was the hardest thing to get used to in linux coming from Windows. In Windows an installed program lives in Program Files and has a shortcut that starts it from it's home folder. That's very different from a namespace collision possible global install that can be run from any folder. I still don't fully agree with it but it makes some things easier. The Windows way also made multiple version installs possible.
- dragonwriter 7y ago
  > In Windows an installed program lives in Program Files and has a shortcut that starts it from it's home folder. And command line tools have that folder added to the PATH, and Windows has a real and ongoing problem with PATH getting too long for the OS to handle when you have enough of them. Windows is GUI optimized with shell as an afterthought, Linux is vice versa.
- Crinus 7y ago
  FWIW you get the same on Linux by installing stuff in /usr/whatever/wherever, /usr/local/whatever/wherever or /opt (which is the closest to Program Files-like place) and making symlinks to the "global" binaries (those meant to be accessible via the shell) while keeping everything else in the application-specific folder. It isn't very uncommon to see binaries inside /usr/bin being symlinks to binaries in other directories, even if you stick with distribution-only packages.
- cmcaine 7y ago
  You can have multiple versions of a program installed in linux. Most package managers won't help you very much with that, but it's about as easy as windows if the programs are interpreted or statically linked or compile easily with your system libraries. NixOS and distri are notable package managers that do make installing different versions of packages pretty easy.

mrighele 7y ago

But a unix system has a module system: the filesystem and its folders. The fact that there are a number of "functions" that are in the same "default namespace" is just a convenience: if needed two binaries with the same name can coexist. Also i will add that in fact the systen binaries are already split: at minimum /usr/bin and /usr/sbin (but also historically, /bin and /sbin although i think in recent linux system the last two are just symlinks to the formers, or the other way around)

ggg3 7y ago

it is also what php did initially :)