Am So., 1. Sept. 2019 um 22:55 Uhr schrieb Neil Van Dyke <>:

> 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.

Maybe the differences in our priorities stem from the differences in the
way that we use racket.
I do not have the perspective of working on multi-person big code bases
with racket and the special gotchas that come up with that.
Maybe that is one requirement that should be considered and talked about
Consider creating an rfc/issue that describes some of the sticking points
with current racket with big projects?
I think it would give valuable insight and allow me and other people to see
problems from a different perspective.
I imagine that there is a big design space of solutions that would help for
big projects and probably also rackety inventions that could still be made.

The reason why I find it appropriate to just call it `watch` is, because
from my personal experience I find it highly unlikely that a file watching
package would be used globally throughout an entire code base. It is much
more likely that it will be used in 1-3 small modules and it is also likely
that those modules will convey a general idea that they are all about
handling files and the require will make it obvious that a file-watching
library is used.
Especially if you are using DrRacket and its ability to show arrows to the
require that provides that identifier.

I think we might not completely agree on the watch example, but it is good
to see the different perspective and something to keep in mind while
further thinking about it.

When it comes to worse is better, I do agree in the sense of getting things
started and producing results in the short term. But I also think that it
is valuable to sometimes take a break on short term solutions and consider
what long term possibilities there could be. This might only result in a
vague idea for future development or direction and you may end up needing
the short term solution anyway, but I think its worth it to try to imagine
different ways of doing things.

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 view this discussion on the web visit

Reply via email to