Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of thoward37@gmail.com designates
 209.85.214.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        b=N97Eq1Mgmo12kHEOzo9F91unrP6SXeMJYcRUGJp9QLL85JcLbQ7dLJXG86DbNsKmrU
         t1UAMGLaHcMyL9Q+N1ztEF2SKx6kt2PPvIzKuEu7nYQLebA4faAn9j+wfbegSyBp+tyJ
         0jRUK3pRMKGWH/Olgi0fwKFJ8iUl9ydXKDS0E=
MIME-Version: 1.0
In-Reply-To: 
 <3FCEA726F7253C4FAC829227E83E051401895E5A46@USPHO-MXVS05.amer.thermo.com>
References: <COL109-DS71F03D96FDE61952EDF75E4320@phx.gbl>
 <SNT144-ds18593C5379550CFD8D8FC1D2320@phx.gbl>
 <AANLkTim0z3F+Z60-adsovaozyN0-Z4KP-RDEb4C0qdEq@mail.gmail.com>
 <AANLkTik6bdm_0rZoNhHqBcMfh2WstSLsX+Q+93jM1iaf@mail.gmail.com>
 <AANLkTimr5r4MBOoJ9LxjnZxj4w8VOSZfvQjL24e80qGr@mail.gmail.com>
 <0683F6EC5D57564184EF0EC1807BAA7D9AEB38@exchange.brainbankinc.com>
 <AANLkTinXS4SXzgVWeNnZHJ7_=tfUQ9VDpbgheeb5LXAN@mail.gmail.com>
 <70F57422AF52CB43AF1CF9FC49F3CC8D2D0567BB30@HO-NT-IS.palmerharvey.co.uk>
 <01a201cb827f$5bfd3750$13f7a5f0$@com> <1a9d01cb8613$97b31e30$c7195a90$@net>
 <3FCEA726F7253C4FAC829227E83E051401895E5A46@USPHO-MXVS05.amer.thermo.com>
From: Troy Howard <thoward37@gmail.com>
Date: Wed, 17 Nov 2010 15:35:06 -0800
Message-ID: <AANLkTinsT1MyVk9gqM2b19hMdSo-FigRKL-KD9=Zdb8P@mail.gmail.com>
Subject: Re: Lucene project announcement
To: lucene-net-dev@lucene.apache.org
Cc: "dev@lucene.apache.org" <dev@lucene.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Neal,

As you said, "If you're developing at the concept level the specific
language you use becomes unimportant. ".

This is exactly why we feel that working on this in C# is not a
problem. We feel that the language should not impede our ability to
contribute. If we develop some interesting or valuable concepts in C#
those could be ported back to Java for inclusion in the Java
implementation of Lucene.

>From an implementation standpoint, we feel that the code should
perform and integrate as effectively as possible into the runtime it's
in. Unfortunately there's no known software runtime that executes
concepts. They execute code written in a specific language. The
details of how that code executes and integrates into applications
directly effects it's performance and usability.

It's a disservice to the concept of Lucene to translate it literally,
if doing so makes it less performant or less usable.

Using human language as an example:

Consider the Chinese name for China:

=E4=B8=AD=E5=9B=BD (Zhong Guo)

translated literally it means "Middle Kingdom".

Imagine you were translating and important philosophical document from
Chinese to English. Would you translate "Zhong Guo" as "Middle
Kingdom" or as "China"?

Suppose someone had asked the original philosopher to write all his
ideas in English to start because "English is the language of
philosophy.. It's what all the eminent philosophers use". Perhaps he
would never contribute his ideas at all, since writing them down in
English is too great a barrier. Maybe he would write them down, but
write them down in a way which made them seem absurd or have less of
an impact.. In other words.. Miss the meaning, even though he'd
translated literally.

Either way, it would be less ideal than simply writing them in Chinese
to start, as that's what would be most natural for our imaginary
philosopher. The burden of translation from Chinese to English could
then be performed by an expert in translation, who would, undoubtedly,
translate the meaning conceptually, not the words syntactically.

Thanks,
Troy


On Wed, Nov 17, 2010 at 12:16 PM, Granroth, Neal V.
<neal.granroth@thermofisher.com> wrote:
> Is Java Lucene "grown up" ? =C2=A0Look at how much discussion it took to =
determine how to get Java out of the name :)
>
> The discussion about advancing the algorithm in C#/.NET seems to be missi=
ng the point. =C2=A0If you're developing at the concept level the specific =
language you use becomes unimportant. =C2=A0However as most of the concept =
developers apparently find Java convenient; others wanting to participate a=
t the concept level would find it more beneficial to join that brain-pool i=
nstead of diluting the effort by starting up elsewhere.
>
>
> - Neal
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, November 16, 2010 10:55 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> This topic has been coming back again and again which I have tried to
> address multiple times, so let me try again.
>
> 1) Java Lucene started years before the first C# version (4+ years if I g=
et
> my history right), thus it defined and has been the definer of the
> technology and the API. =C2=A0It is the established leader, and everyone =
else is
> just a follower.
>
> 2) Lucene.Net is no were mature as Java Lucene, never got established
> itself, or had a rich development community -- thus why we are here today=
.
>
> 3) If and only if, the community of Lucene.Net (or "Lucene" over at
> codeplex.com) manages to proves itself to the level of Java Lucene, only
> then such a community will have the voice to influence folks over at Java
> Lucene. =C2=A0Only then you will see the two community discussing search =
engine
> vs. port issues or the state of Lucene.Net.
>
> If you look in my previous posts, I have pointed those out. =C2=A0We must=
 first:
>
> 1) Be in par with Java Lucene release and keep up with commit-per-commit
> port.
>
> 2) Prove Lucene.Net is a grownup project with followers and a healthy
> community (just like Java Lucene).
>
> If we don't achieve the above, folks over at Java Lucene will not take us
> seriously, and thus we can't influence them.
>
> -- George
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
> Sent: Friday, November 12, 2010 10:36 AM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> Paul, et al,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul, God bless you. =C2=A0This is probably th=
e most rational, practical
> perspective I've seen on the whole matter since the debacle started.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0While Lucene started off as a Java project, it=
's massive success
> indicates that the concepts around it are very desirable by developers in
> other technologies, and that the Java product isn't being translated well
> into those technology stacks.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0That's not a slight against those who have con=
tributed to this point
> to try and keep the .NET version in line with the Java one (despite me
> thinking that the actual approach to doing so is a horribly misguided
> approach).
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0That said, there should be a serious conversat=
ion with the
> Java-version folk about making this happen. =C2=A0How can Lucene be
> abstracted/standardized in a non-technology-stack-specific way that other
> technology stacks can create implementations against that
> abstraction/standard.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Is it too much to ask of the Java folk? =C2=A0=
Perhaps. =C2=A0After all, they
> haven't done it yet and it doesn't seem like they see the need for this.
> This isn't an unjustified position; that project has a massive user base =
and
> success which creates massive responsibilities to the project that must b=
e
> fulfilled.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0If such a thing proceeds, this is what I'd lik=
e to see in such an
> abstraction:
>
> - Technology-agnostic concepts used, down to the class level:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Classes might be the one exception, they are=
 near universal.
> However, this could be something like "entity"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Properties - Java doesn't have properties, t=
hey have a property
> convention. =C2=A0.NET has the concept of a property, which translates to=
 a named
> getter and/or setter which can execute additional code on either in addit=
ion
> to the assignment.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Fields - Raw exposed data points. =C2=A0Whet=
her or not these ^should^
> be used is a different story, but there are some places where they are us=
ed
> so a definition is needed.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Methods - Functions/methods, whatever you wa=
nt to call them, we
> all know what they are.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- In the end, the names are not important as m=
uch as the
> abstractions are, I think we all have an idea on what they are.
> - Right now, I don't have a problem with a class-by-class mapping, but ov=
er
> time, whether or not class design was done to suit the technology should =
be
> addressed, and ultimately abstracted out if this is the case.
> - Things like ^what^ is returned from methods or internal constructs that
> are used to make guarantees about behavior and the like should be abstrac=
ted
> out. =C2=A0For example, in Lucene.NET we have the following (in order to =
maintain
> a line-by-line port in most cases):
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- A custom implementation of ReaderWriterLock.=
 =C2=A0There's no reason
> for something like this.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Accepting and returning arrays even when the=
 elements in the
> arrays are read only. =C2=A0In this case, there should be hard definition=
s as to
> whether or not an IEnumerable would be better, since .NET has such great
> support for deferred execution now. =C2=A0Of course, if you ^need^ a mate=
rialized
> list at some point, then an array is fine, but I imagine there are ^many^
> places where deferred execution would be a huge boon.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Transactional behavior on IndexWriter - I'd =
love to see this
> interact with the Transaction framework that was put in with .NET 2.0.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't expect any abstraction that comes out =
(if one does) to
> follow the above, it's just the things that stick out to me initially.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Moving on to other issues (the Java Lucene fol=
k can tune out here if
> they wish, but feel free to read on!). =C2=A0First, I've seen others on t=
his list
> express a desire to make Lucene.NET more ".NET friendly", on this point, =
I
> can't agree more.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0However, there is massive disparity on what pe=
ople consider ".NET
> friendly"; does it mean wrappers around existing code, better use of .NET
> technologies to implement internal functionality, or ".NETifying" things
> like properties and the like? =C2=A0All of those suggestions (and some ot=
hers I'm
> sure) have been posted at one point or another.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0If Paul's idea of a Lucene "standard" was real=
ized, then all of this
> becomes a moot point. =C2=A0For those that say "the Java version is the
> standard", re-read the fourth paragraph, the part about technology-agnost=
ic.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Now, while I don't feel my opinion about wheth=
er or not it is a good
> idea for people to start their own projects to realize a their vision of =
a
> more ".NET friendly" version of Lucene for .NET is relevant, I will wish
> them well.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0However what is saddening is the feedback that=
 I've seen from people
> on this list and in others projects workspaces towards those projects whi=
ch
> are. =C2=A0NO ONE has the right to say "you should not do that"; if that =
person
> wants to head up that project, so be it, they are moving in the direction
> their conscience/heart/mind tells them to go. =C2=A0Just because you don'=
t agree
> with it to be the best step forward doesn't mean they have earned your
> indignation.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0It's another thing altogether to say "hey, ^wo=
uld you^ consider
> doing the work here, as we could use your help", or something along those
> lines, the key word being "would". =C2=A0That's a request, "you should" i=
s a
> demand.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Unfortunately, that's not what is happening in=
 and out of the list
> and it's behavior that I hope is curbed immediately.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Nick
>
> -----Original Message-----
> From: Paul Hadfield [mailto:Paul.Hadfield@palmerharvey.co.uk]
> Sent: Friday, November 12, 2010 3:14 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> It feels to be that the problem is being approached a* about face (i.e. t=
he
> wrong way wrong). =C2=A0Maybe it is the way that ASF works but do the con=
straints
> of Java define "Lucene, or should it bigger than that? =C2=A0Should Lucen=
e be a
> full text engine concept that can safely be developed in multiple languag=
es?
> I'm sure everyone would agree that it would be silly to have different
> underlying file/data formats and it would definitely make sense that the
> rules for processing should be the same. =C2=A0 But could the developers =
behind
> Lucene.JAVA and Lucene.NET work together to define an independent Lucene
> project and road-map, etc. =C2=A0This could then be developed in each lan=
guage
> independently of each other and heaven forbid, Oracle managed to destroy =
all
> that is good about Java then Lucene would continue regardless, etc.
>
> However, if the above (dream?) could not be met, I can't see any way othe=
r
> than keeping with a direct port in the short term. =C2=A0Once it is prove=
n that
> Lucene.NET can keep up with the Java development, then it might be possib=
le
> to think about something other than a direct port. =C2=A0This would simpl=
y be
> because every Lucene.NET release is currently trying to catch up with 'x'
> Lucene releases and it feels like anything other than a direct port would
> make that nigh on impossible to determine what needs to be implemented in
> the .NET version.
>
> =C2=A0- Paul.
>
> -----Original Message-----
> From: Hans Merkl [mailto:hm@hmerkl.com]
> Sent: 11 November 2010 21:53
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Lucere project announcement
>
> Keep in mind that Java Lucene is being developed actively. Once you
> start to optimize for .NET, it will become harder and harder to keep
> up with future Java Lucene development.
>
> Whats does MPS do that may be useful for Lucene.NET?
>
> On Thu, Nov 11, 2010 at 14:54, Karell Ste-Marie <stemarie@brain-bank.com>
> wrote:
>> I have done no other past contribution other than use the product,
>>
>> Can I be reminded, once again, why we don't use the .NET Optimized
>> approaches instead of doing a straight code-code port?
>>
>> I understand that the whole purpose of the project is to be a Lucene
>> port to .NET, but should we not at some point in time optimize more for
>> .NET than just continue to try and port more Java to .NET code? From
>> Scratch? Each and every version?
>>
>> It seems to be that if that is the approach then perhaps it would be
>> time better spent to look into a tool such as MPS
>> (http://www.jetbrains.com/mps/) and then use the source java language
>> through this which would product .NET code on the other side.
>>
>> Or perhaps I've just managed to place a size-12 foot in my mouth because
>> the current process is actually almost exactly this today?
>>
>> Comments welcome...
>>
>>
>>
>> Karell Ste-Marie
>> C.I.O. - BrainBank Inc
>> (514) 636-6655
>>
>
>
> **********************************************************************
> --=3DDisclaimer=3D--
> This communication is to be treated as confidential and the information
> contained in it may not be used or disclosed except for the purpose for
> which it has been sent. If you have received this communication in error,
> please destroy it immediately and notify postmaster@palmerharvey.co.uk. A=
ny
> defamatory statements or infringements of copyright or licenses by employ=
ees
> of Palmer & Harvey McLane Limited are contrary to company policy. The
> company will not accept any liability in respect of such a communication.
> Computer viruses can be transmitted by email. The recipient should check
> this email and any attachments for the presence of viruses. Palmer & Harv=
ey
> McLane Limited accepts no liability for any damage caused by any virus
> transmitted by this email.
>
> Palmer & Harvey McLane Limited.
> Company registered in England & Wales. Regd. No. 1874153.
> Regd Office P&H House, Davigdor Road, Hove, East Sussex, BN3 1RE.
> **********************************************************************
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org