lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <>
Subject Re: Lucene project announcement
Date Wed, 17 Nov 2010 23:35:06 GMT

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:

中国 (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.


On Wed, Nov 17, 2010 at 12:16 PM, Granroth, Neal V.
<> wrote:
> Is Java Lucene "grown up" ?  Look 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 missing the point.
 If you're developing at the concept level the specific language you use becomes unimportant.
 However as most of the concept developers apparently find Java convenient; others wanting
to participate at the concept level would find it more beneficial to join that brain-pool
instead of diluting the effort by starting up elsewhere.
> - Neal
> -----Original Message-----
> From: George Aroush []
> Sent: Tuesday, November 16, 2010 10:55 PM
> To:
> Cc:
> 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 get
> my history right), thus it defined and has been the definer of the
> technology and the API.  It 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
> 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.  Only 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.  We 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] []
> Sent: Friday, November 12, 2010 10:36 AM
> To:
> Cc:
> Subject: RE: Lucene project announcement
> Paul, et al,
>        Paul, God bless you.  This is probably the most rational, practical
> perspective I've seen on the whole matter since the debacle started.
>        While 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.
>        That's not a slight against those who have contributed 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).
>        That said, there should be a serious conversation with the
> Java-version folk about making this happen.  How can Lucene be
> abstracted/standardized in a non-technology-stack-specific way that other
> technology stacks can create implementations against that
> abstraction/standard.
>        Is it too much to ask of the Java folk?  Perhaps.  After 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 be
> fulfilled.
>        If such a thing proceeds, this is what I'd like to see in such an
> abstraction:
> - Technology-agnostic concepts used, down to the class level:
>        - Classes might be the one exception, they are near universal.
> However, this could be something like "entity"
>        - Properties - Java doesn't have properties, they have a property
> convention.  .NET has the concept of a property, which translates to a named
> getter and/or setter which can execute additional code on either in addition
> to the assignment.
>        - Fields - Raw exposed data points.  Whether or not these ^should^
> be used is a different story, but there are some places where they are used
> so a definition is needed.
>        - Methods - Functions/methods, whatever you want to call them, we
> all know what they are.
>        - In the end, the names are not important as much 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 over
> 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 abstracted
> out.  For example, in Lucene.NET we have the following (in order to maintain
> a line-by-line port in most cases):
>        - A custom implementation of ReaderWriterLock.  There's no reason
> for something like this.
>        - Accepting and returning arrays even when the elements in the
> arrays are read only.  In this case, there should be hard definitions as to
> whether or not an IEnumerable would be better, since .NET has such great
> support for deferred execution now.  Of course, if you ^need^ a materialized
> list at some point, then an array is fine, but I imagine there are ^many^
> places where deferred execution would be a huge boon.
>        - Transactional behavior on IndexWriter - I'd love to see this
> interact with the Transaction framework that was put in with .NET 2.0.
>        I 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.
>        Moving on to other issues (the Java Lucene folk can tune out here if
> they wish, but feel free to read on!).  First, I've seen others on this list
> express a desire to make Lucene.NET more ".NET friendly", on this point, I
> can't agree more.
>        However, there is massive disparity on what people 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?  All of those suggestions (and some others I'm
> sure) have been posted at one point or another.
>        If Paul's idea of a Lucene "standard" was realized, then all of this
> becomes a moot point.  For those that say "the Java version is the
> standard", re-read the fourth paragraph, the part about technology-agnostic.
>        Now, while I don't feel my opinion about whether 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.
>        However what is saddening is the feedback that I've seen from people
> on this list and in others projects workspaces towards those projects which
> are.  NO 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.  Just because you don't agree
> with it to be the best step forward doesn't mean they have earned your
> indignation.
>        It's another thing altogether to say "hey, ^would you^ consider
> doing the work here, as we could use your help", or something along those
> lines, the key word being "would".  That's a request, "you should" is a
> demand.
>        Unfortunately, that's not what is happening in and out of the list
> and it's behavior that I hope is curbed immediately.
>                - Nick
> -----Original Message-----
> From: Paul Hadfield []
> Sent: Friday, November 12, 2010 3:14 AM
> To:
> Subject: RE: Lucene project announcement
> It feels to be that the problem is being approached a* about face (i.e. the
> wrong way wrong).  Maybe it is the way that ASF works but do the constraints
> of Java define "Lucene, or should it bigger than that?  Should Lucene be a
> full text engine concept that can safely be developed in multiple languages?
> 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.   But could the developers behind
> Lucene.JAVA and Lucene.NET work together to define an independent Lucene
> project and road-map, etc.  This could then be developed in each language
> 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 other
> than keeping with a direct port in the short term.  Once it is proven that
> Lucene.NET can keep up with the Java development, then it might be possible
> to think about something other than a direct port.  This would simply 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.
>  - Paul.
> -----Original Message-----
> From: Hans Merkl []
> Sent: 11 November 2010 21:53
> To:
> 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 <>
> 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
>> ( 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
> **********************************************************************
> --=Disclaimer=--
> 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 Any
> defamatory statements or infringements of copyright or licenses by employees
> 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 & Harvey
> 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.
> **********************************************************************

View raw message