Towards the end of the first chapter
279 views
Skip to first unread message
Erik Assum
Mar 17, 2016, 6:01:35 PM3/17/16
to elements-...@googlegroups.com
This is nitpicking, but towards the end of the first chapter, where you discuss function names, you talk about functions which pull, transform, and push. I like that. But I do feel that the discussion on how functions should only do one of those actions belong somewhere else than in a chapter on naming.
Erik.
--
i farta
Erik.
--
i farta
Zach Tellman
Mar 17, 2016, 6:06:22 PM3/17/16
to Erik Assum, elements-...@googlegroups.com
It's definitely something I'll talk about more in the "Indirection" chapter, but I wanted to clarify why I only discuss names for each of the three, rather than all possible permutations. Maybe that will turn into a footnote referencing the third chapter, once it exists.
--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clo...@googlegroups.com.
To post to this group, send email to elements-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elements-of-clojure/02D07FA4-A602-416B-9302-E5D2AF381F29%40assum.net.
For more options, visit https://groups.google.com/d/optout.
Rick Moynihan
Mar 17, 2016, 7:46:18 PM3/17/16
to Elements of Clojure, er...@assum.net
Hi Zach,
I've just finished reading the first chapter. So far I think this is a really great introduction to idiomatic Clojure / style. Well done! It's funny how I find what you describe to be similar to how I think about naming things in Clojure; though much better articulated.
For what its worth I think the push/pull/transform discussion does belong here.
What I'm curious about however is whether you've consciously resisted the urge to discuss complecting. I appreciate introducing this term might warrant a lot more explanation, however it's a good property of Clojure naming that purposeful complection is easy to detect by name alone, as functions have names like "register-user-account-and-sign-in".
I thought that the discussion on page 14 might have touched on this.
Also on the topic of namespace names, you say that "Namespaces should hold functions that share a common purpose, so that the namespace lends narrowness to the names inside it". This sounds like good advice and is something I've suggested people do too however I think some examples would be useful along with a deeper explanation on what you mean.
For example a few of our projects have a namespace arrangement which would superficially appear to follow your advice; however I find their arrangement hard to navigate. Functions have been assigned to namespaces primarily based upon their layer or kind e.g. all database access functions are arranged together, even if they're querying very different things.
You can get away with this on smaller code bases, but for larger systems it becomes very hard to understand an application, as namespaces don't tend to reflect features or the domain you're modelling.
This might well be straying out of the naming topic and into other chapters but I think helping people avoid these mistakes would be useful. It's certainly something I'd appreciate more advice on! :-)
Thanks again,
R.
I've just finished reading the first chapter. So far I think this is a really great introduction to idiomatic Clojure / style. Well done! It's funny how I find what you describe to be similar to how I think about naming things in Clojure; though much better articulated.
For what its worth I think the push/pull/transform discussion does belong here.
What I'm curious about however is whether you've consciously resisted the urge to discuss complecting. I appreciate introducing this term might warrant a lot more explanation, however it's a good property of Clojure naming that purposeful complection is easy to detect by name alone, as functions have names like "register-user-account-and-sign-in".
I thought that the discussion on page 14 might have touched on this.
Also on the topic of namespace names, you say that "Namespaces should hold functions that share a common purpose, so that the namespace lends narrowness to the names inside it". This sounds like good advice and is something I've suggested people do too however I think some examples would be useful along with a deeper explanation on what you mean.
For example a few of our projects have a namespace arrangement which would superficially appear to follow your advice; however I find their arrangement hard to navigate. Functions have been assigned to namespaces primarily based upon their layer or kind e.g. all database access functions are arranged together, even if they're querying very different things.
You can get away with this on smaller code bases, but for larger systems it becomes very hard to understand an application, as namespaces don't tend to reflect features or the domain you're modelling.
This might well be straying out of the naming topic and into other chapters but I think helping people avoid these mistakes would be useful. It's certainly something I'd appreciate more advice on! :-)
Thanks again,
R.
On Thursday, 17 March 2016 22:06:22 UTC, Zach Tellman wrote:
It's definitely something I'll talk about more in the "Indirection" chapter, but I wanted to clarify why I only discuss names for each of the three, rather than all possible permutations. Maybe that will turn into a footnote referencing the third chapter, once it exists.
On Thu, Mar 17, 2016 at 3:01 PM Erik Assum <er...@assum.net> wrote:
This is nitpicking, but towards the end of the first chapter, where you discuss function names, you talk about functions which pull, transform, and push. I like that. But I do feel that the discussion on how functions should only do one of those actions belong somewhere else than in a chapter on naming.
Erik.
--
i farta
--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clojure+unsub...@googlegroups.com.
Erik Assum
Mar 18, 2016, 2:16:49 AM3/18/16
to Rick Moynihan, Elements of Clojure
Hi Rick and Zachary,
Your mentioning of namespaces got me thinking about stuff I've thought about before. In most any language which uses a framework to achieve things, packages/namespaces are named after the implementation details they represent. Eg 'foo/models', 'foo/views', and 'foo/controllers'.
This tells me nothing about what the application is about nor what it can do.
Would it be appropriate with a discussion on wether namespaces should reflect the domain of the application or not? And if so, in which way?
Erik.
-- i farta
Zach Tellman
Mar 18, 2016, 8:02:06 AM3/18/16
to Elements of Clojure, Rick Moynihan, er...@assum.net
Hi Rick,
Many of the ideas that are discussed in the "Names" chapter will be expanded upon in the chapter on "Indirection", namespaces included. With that said, I did try to discuss both organizing by data scope (or layer, as you say) or datatype. I suggest avoiding the "one namespace per datatype" approach only where there are a large number of datatypes, because we don't want to have too many namespaces. It seems like in your case, it's worth having a few more. I'll think about how I can be more clear about this in the first chapter, and how I should expand on it in the third.
Many of the ideas that are discussed in the "Names" chapter will be expanded upon in the chapter on "Indirection", namespaces included. With that said, I did try to discuss both organizing by data scope (or layer, as you say) or datatype. I suggest avoiding the "one namespace per datatype" approach only where there are a large number of datatypes, because we don't want to have too many namespaces. It seems like in your case, it's worth having a few more. I'll think about how I can be more clear about this in the first chapter, and how I should expand on it in the third.
As to the rest, I'm not wild about the "complection" neologism. Putting aside Rich's definition in the talk, I feel like it's used to describe two separate problems:
* treating two distinct ideas as the same (which is adequately captured by "conflate")
* implementing two clearly distinct ideas in a way where they're not easily separated
* treating two distinct ideas as the same (which is adequately captured by "conflate")
* implementing two clearly distinct ideas in a way where they're not easily separated
Obviously the first problem can lead to the second one, but I think they are different enough that they should be talked about separately. Using the terminology in the book, I think it's more clear to talk about the second problem as "insufficient indirection". Again, though, I'll give it some thought. Nothing's set in stone.
Thanks,
Zach
To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clo...@googlegroups.com.
To post to this group, send email to elements-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elements-of-clojure/02D07FA4-A602-416B-9302-E5D2AF381F29%40assum.net.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clo...@googlegroups.com.
To post to this group, send email to elements-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elements-of-clojure/58d3ce70-d908-4ec2-bcb9-12f812f64d99%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages