Simon Schlee wrote on 9/1/19 3:28 PM:
Try not to make identifiers be simple generic terms, like `watch`
I strongly disagree with this statement.
I think what you say is valid, and I agree in some situations.
However, we're talking about reusable third-party packages, which are
used pretty much the same as much of the "standard library" of Racket.
When I look at the Racket Reference, the standard library tends to use
descriptive names, like `file-or-directory-permissions` rather than
`permissions`.
A third-party package analog might be `watch-file-or-directory` (or
whatever the rough purpose is) rather than `watch`.
The way racket does imports is one of the things I highly value
because you can use modules to aggregate identifiers from different
modules/packages,
resolve name conflicts by renaming / or not exporting the 2
identifiers that clash.
This creates a lot of freedom to create specific sets of functionality
exported by one simple module.
This way I can create my custom set of things which are most needed in
the particular codebase.
Instead of having to write 40 lines of requires like you have to in
other languages.
True, that kind of module coupling often happens, and a module to
aggregate a class of exports used by a codebase can be very convenient.
That aggregating module might also, as you said, be an opportunity to
fix the problems created by having all those modules export terse
generic names rather than more descriptive ones.
BTW, one drawback to the exports-aggregating module for a codebase comes
when any of the aggregated modules changes (or the exports change,
depending on how simple the compiler's sense of dependencies and
changes). In a large system, for an aggregating module used widely,
this can cause needing to recompile much of the codebase (which can be
costly, in the size of system in which I think one would consider making
an aggregating module like that). Imagine the perhaps not-unusual
situation of changing a module actually only used by 10% or 1% of the
modules that import the aggregating module. Coincidentally, the largest
Racket system I worked on had a couple such aggregating modules, which
initially made sense, until they were covering way too much stuff that
got changed way too frequently, and it made the code base way more
cumbersome to work with than just having the appropriate `require`s
would be. (Auto-updating the `require`s would've been nice, though.)
One of them actually made a lot of sense initially -- it was a logical
whole that was unlikely to change -- until that thing got more things
added to it, and until we needed to actively work on that thing while
testing it integrated with the system (unit tests aren't always
sufficient, or aren't always the most expedient).
Finding things in the documentation is a whole other technical issue.
I agree that could be improved. One bit of obvious low-hanging fruit
(with IDE integration) is having the context of your current #lang and
requires as factors in search hit rankings. (I'm not criticizing the
current documentation search; it works surprisingly well for offline
search, and with not that much resources, and was very clever in how it
was implemented. I think it might've been by Eli Barzilay.)
In the interim, a boost comes from descriptive names (which also happens
to be idiomatic Racket, and idiomatic Racket). That boost might be
worse-is-better, but it works. https://en.wikipedia.org/wiki/Worse_is_better
Also, I don't think Web searches, such as of forum posts/messages,
articles, code repos, etc., are sensitive to ad hoc import renaming. So
you might get better global search hits for "racket
file-or-directory-permissions" than "racket file permissions".
*
Racket2 aside, since you might be looking for terseness in some
regard... One of the higher-level (but not top-level) requirements for
Racket2 might concern terseness. Not just in naming, but in other
things as well (e.g., does a mutating or definition form also produce a
value, so that it can be embedded in, say, the condition of a loop; and
perhaps somehow easing the burden of expressing big imports sets). Base
Scheme is one of the less-terse of languages I know, and that took a
little getting used to, though eventually I decided it resulted in a
good balance of overall readability (and I could layer over the base
when that helped). But maybe Racket2 decides to go more terse in the
base, which might be reasonable. In any case, that's a bit of language
design space choices, which, in the context of Racket, I think should be
traced back to top-level requirements (e.g., why is the language being
made at all, for whom, for what purposes, and why that), and influence
much of the other requirements below it. (I'm saying "requirements"
lately because it's a software engineering framework that should help us
be clear about things we haven't yet been, though I initially thought we
didn't need the formality.)
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/8b393816-9c57-cebd-f354-a09a9610a532%40neilvandyke.org.
