5 ms·
Where all these grand proposals break down is when you actually have to deal with real, domain-specific problems. It's not too hard to clearly express what the
by akeefer 15y ago
Where all these grand proposals break down is when you actually have to deal with real, domain-specific problems. It's not too hard to clearly express what the split_string() function or the multiply() function do, so namespace collisions aren't a problem. But what about the function that "assigns" an "activity" to a "user?" All of a sudden, every single person is going to mean something different by those three words, and it suddenly requires a huge amount of context to find that function. Searching for something that assigns activities to users as some sort of global search is worthless; the only stuff you care about is the set of functions within your code base that deal with those concepts, or perhaps within some library that you understand and whose notions of users, activities, and assignment matches what you need to do. So you need some unit to pull in that's larger than just a bag of functions; you need a group of functions that collectively operate on the same sets of data in consistent ways. And that's just a fundamentally hard problem; finding the right split so that you have a set of functions that can be used together, that are reusable, that don't rely on or expose additional concepts or libraries, that's all very difficult. Just flattening the function namespace, killing modules, and doing global searches doesn't do anything for that problem. Again, as much as we all wish that the proper unit of reusability in programming is a single function, since it makes life easier, in most complicated cases that's simply not the case. That's why we have classes, or modules, or namespaces, or packages in the first place: they're all various attempts to group together functions that work together on the same kinds of data, that share the same understanding of that data and that work towards the same goal. Just punting on that encapsulation problem doesn't make it go away.
- bartonfink 15y agoJust to play devil's advocate, you might be able to handle this by hacking types through Erlang's pattern matching syntax. Thus, you might have a function assign_activity(("KeeferUser", user_no), ("KeeferActivity", activity_no)) and rely on the compiler to match the "type" in the first field of each tuple you pass. It's not pretty, but it is possible.
- akeefer 15y agoThere are plenty of ways to skin that particular cat, and languages exist and are successful without modules or namespaces or classes (like C). It's just a question of whether or not the proposal in the article is an improvement upon anything, and I think it's reasonable to argue that no, it's not; people added those features to more recent languages because they solved real problems. Replacing explicit, required, rigid categorization with optional, flexible categorization isn't necessarily a win: it could just mean that people don't actually think about the problem very hard, and you end up being unable to find all the things related to X when you actually decide you need to understand how X works, because people didn't bother adding in the "X" tag in the function metadata to everything related to X.
- skrebbel 15y agoC has modules all right. A .c/.h file pair is essentially what many other languages call a module, and have all the problems that the modules in Joe Armstrong's fibonacci example also has.
- joelangeway 15y agoHe is probably imagining that the name of that function would be "nameofproject_assign_user_activity/2", and that you would typically use it along with some others from the same source, following some conventions. Seems that obviates modules to me. In Erlang you give the name of the module with a function anyway, so names like that harm nothing. It would be real nice to type "map" instead of "lists:map" though.
- akeefer 15y agoSure . . . I mean, C doesn't exactly have namespaces, and neither did PHP at first, and you can write code in them, so it's not that it's somehow not possible to uniquely name functions. But it's pretty annoying, and I'd say that many people who are used to modules and namespaces miss them when they move to a world that doesn't have those things. They exist as A) syntactic sugar, so that you can just say assign_user_activity() instead of my_company_my_project_assign_user_activity and B) as a strong organizing principle (potentially that has tooling around it). The former point is just annoying; my argument was that the latter is really the point of modules or namespaces. Maybe I want to find all the functions related to assignment: how do I do that? Do I just look on disk? Do I use tags or metadata? Do I assume some naming convention? It's a problem you have to solve somehow, and solving it requires effort, because it's an explicit organizational effort. Modules or namespaces or packages or classes give you a way to say "this stuff goes together" and to encapsulate and abstract large units of related functionality, and to do so in a way that tools and programs understand. In a Java IDE, my IDE will auto-complete all the functions on a class; in a REPL I can just print out all the methods on an object. That's a useful organizing principle, and it's one that you lose if you totally flatten the namespace. You could argue that organization isn't one-dimensional or hierarchical, which is what namespaces and such force on you, and it's a reasonable statement. But replacing it with nothing explicit and relying on extensive developer metadata and documentation so you can search for things? That seems even more idealistic. When was the last time you saw every single function, even private ones, documented and tagged so correctly and up-to-date on a real-world, large-scale project that you'd rely on them to serve as the only organizing principle in your application?