Michael McCandless wrote:
Well... I would expect & hope Lucene's adoption is growing with time,
so the number of new users should increase on each release. For a
healthy project that's relatively young compared to its potential user
base, that growth should be exponential.
And, I'd expect the vast majority of old users don't ever upgrade.
Furthermore, when a reviewer (typically a "new user") tests Lucene
against other search engines, and fails to check our Wiki for all the
things we all know you have to do to get good search or indexing
performance, and then reports in a well-read blog somewhere that
Lucene's performance isn't great when compared to other search
engines, and lots of other people read that, cite it, share it, etc.,
those people are less inclined to try Lucene. This then stunts
Lucene's growth.
I would think a reviewer would have to read something other than just
javadocs to figure out how to set up Lucene. While the javadocs are
good, and getting better, I did not find them helpful at first. The
class-at-a-time approach to documentation is too fragmented for me. So,
what is it that they use that leads to such unfavorable results?
Yes, we all sit here and say "well that's not a fair review because
you didn't properly tune Lucene", yet, this kind of thing happens all
the time. If Lucene had better defaults out of the box it'd reduce
how often that happens.
Mike
On Fri, May 22, 2009 at 2:49 PM, DM Smith <dmsmith...@gmail.com> wrote:
Michael McCandless wrote:
On Fri, May 22, 2009 at 2:27 PM, DM Smith <dmsmith...@gmail.com> wrote:
Marvin Humphrey wrote:
I feel the opposite: I'd like new users to see improvements by
default, and users that require strict back-compate to ask for that.
By "strict back-compat", do you mean "people who would like their search
app to
not fail silently"? ;) A "new user" who follows your advice...
// haha stupid noob StandardAnalyzer analyzer = new
StandardAnalyzer(Versons.LATEST);
... is going to get screwed when the default tokenization behavior
changes.
And it would be much worse if we follow my preference for making the arg
optional without following my preference for keeping defaults intact:
// haha eat it luser StandardAnalyzer analyzer = new
StandardAnalyzer();
It's either make the arg mandatory when changing default behavior and
recommend that new users pass a fixed argument, or make it optional but
keep
defaults intact between major releases.
I think I see your point: A new user is such only for the first release
that
they use Lucene. For a first use, there is no backward compatibility
problem. On the use of a subsequent release, their code still gets the
latest and greatest and now by the choice they were guided to make, they
may
have broken backward compatibility.
So for any user, the only save, thus acceptable use is to never have
Versions.LATEST, but only a specific version.
Right, we would have to not provide Versions.LATEST, ie if you want
latest, you'd pick Versions.LUCENE_29 (in 2.9).
Why go to all this trouble for a new user?
Let's pretend that there are 1,000 new users every release. After 12
releases, there are still only 1000 new users but now 11000 old users.
How does it help an old user?
Those 11000 old users now have to update their code to Versions.Lucene_301
(or whatever the latest is) to get the latest changes, but they are also
going to have to understand what that means and figure out what parts of
their application now behave in a broken manner. Where are they to go to
find out that info? CHANGES.txt?
When I was a new user, I had to look at example code, read faqs, wiki,
javadoc, java-users .... It was a learning curve, fortunately not steep.
Don't those resources need to be maintained so as to match the
best/recommended practices? Can't that be the place where new users are
informed?
-- DM
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
