I agree with David. I use grep 1000 times a day and I do know how to use a
> computer (and do not appreciate being patronised), but I also use
> serach_src() in the middle of Sage sessions a lot and tha seems much more
> useful to me than switching to a different window and navigating to
> wherever my Sage source code is.
>
>>
>>
<nearflame>
I'm on this side, for slightly different reasons. Having an *option* that
is just a Sage function is something that should not be removed. If it
hadn't existed, maybe we don't build it, but there is no need to remove it.
Especially since we still don't (to my admittedly somewhat dated
knowledge) have an easy way to search for partial words using
tab-completion, so there should be a nice way to do so:
https://sagecell.sagemath.org/?q=xlwrqs
Contrast with "!grep genvecto *" which is still running many seconds later
- and doesn't give me only definitions. And that's because I used it in a
directory which I knew wouldn't have many (or any). Try this:
sage: !grep genvecto *
grep: ActiveGSLocalData: Is a directory
grep: Applications: Is a directory
<snip>
Oh, so now I have to use the -r flag ... but of course I'm in my HOME
directory now. Still waiting for the first one to show up, undoubtedly all
my linear algebra materials should start cropping up. Ooh, if I start it
from that directory I get all kinds of non-Sage matches (37).
So now we have to teach the user about directory structure of the Sage
bundle - after all, do we search the src/ directory or the local/
directory? How do I find it from where I installed it? Maybe this user
has just laboriously created a symlink so they don't have to cd into the
Sage directory every time, but now to search we have to. Ugh.
By contrast, I used search_def (in my view, the most important of the
search_* functions) all the time when I would have been scared off by grep.
If it is so slow, then in the documentation just put a WARNING:: block
that it is slow and where to find out how to use !command. I am always
amazed by how unaware Sage developers, past and present, are of the
difficulties people who are not used to command line have.
This is why people keep using things like SPSS for newcomers in intro stats
- even though there are many good books using R at a similar level.
Because the interface is one people already scared of stats can at least
sort of figure out. I know of many experts in their fields who do just
fine in publication, but stay as far away from non-GUI applications as they
can, because (in their view) the time to learn how to use command line
properly for every conceivable thing is a poor investment, as opposed to
actually running experiments. You can say they are wrong, or even mock
them, or say we shouldn't have added these and given everyone a lesson in
grep instead, but that is no reason to remove a function that works well
enough for use. And I'm certainly not suggesting we build something like
this: https://reference.wolfram.com/language/howto/SearchForHelp.html
As for the log functions, that is not necessarily a newbie function in any
case! And if it doesn't work anyway ... completely different situation. I
get that Python is the anti-Perl, "only one obvious way to do it". That
doesn't work so well in real life.
</nearflame>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/a031849b-6c56-4401-994c-b566b262843b%40googlegroups.com.
