Proposed Contribution to Apache Commons,

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposed Contribution to Apache Commons,

norm-2
My colleague Jeff Rothenberg and I, retirees, have developed an alternative to
using regular expressions for searching for (and optionally replacing)
patterns in text. We believe it is generally useful to Java programmers and
would like to contribute it to Apache Commons, where we will continue to be
active in maintaining the software. You can find the software and associated
documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.

Please let us know what further steps we should take to have our contribution
considered.

Thank you,

    Norman Shapiro

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

garydgregory
Norman,

Hello and welcome to Apache Commons.

It's not clear to me why Naomi is better than regular expressions. Pointing
to Javadocs is not the best way to get traction.

Your project would be better served by having some documentation on your
front page with an example driven tutorial.

Is Naomi faster than REs?

What can I do in Naomi that REs can't do? And vice-versa.

Examples of this on your front page would help you at least get folks to
consider learning a brand new way of doing things...

Gary



On Tue, Sep 29, 2015 at 1:06 PM, <[hidden email]> wrote:

> My colleague Jeff Rothenberg and I, retirees, have developed an
> alternative to
> using regular expressions for searching for (and optionally replacing)
> patterns in text. We believe it is generally useful to Java programmers and
> would like to contribute it to Apache Commons, where we will continue to be
> active in maintaining the software. You can find the software and
> associated
> documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.
>
> Please let us know what further steps we should take to have our
> contribution
> considered.
>
> Thank you,
>
>     Norman Shapiro
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Dave Brosius-2
Perhaps i am blind, but i don't see any maven, ant or gradle build
files. You really need to add these for your code base to be accessible
to others wanted to uptake it. (Hopefully maven).

--dave

On 09/29/2015 06:55 PM, Gary Gregory wrote:

> Norman,
>
> Hello and welcome to Apache Commons.
>
> It's not clear to me why Naomi is better than regular expressions. Pointing
> to Javadocs is not the best way to get traction.
>
> Your project would be better served by having some documentation on your
> front page with an example driven tutorial.
>
> Is Naomi faster than REs?
>
> What can I do in Naomi that REs can't do? And vice-versa.
>
> Examples of this on your front page would help you at least get folks to
> consider learning a brand new way of doing things...
>
> Gary
>
>
>
> On Tue, Sep 29, 2015 at 1:06 PM, <[hidden email]> wrote:
>
>> My colleague Jeff Rothenberg and I, retirees, have developed an
>> alternative to
>> using regular expressions for searching for (and optionally replacing)
>> patterns in text. We believe it is generally useful to Java programmers and
>> would like to contribute it to Apache Commons, where we will continue to be
>> active in maintaining the software. You can find the software and
>> associated
>> documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.
>>
>> Please let us know what further steps we should take to have our
>> contribution
>> considered.
>>
>> Thank you,
>>
>>      Norman Shapiro
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Dave Brosius-2
Also the source code is not in the proper package structure. The class's
have packages, but are just dumped directly in src. There is javadoc,
but just dumped in the main folder. I just dump that, and having support
building the javadoc from build tools. Setting the structure of the
project up into some sane will help get people to look at it. I'd again
strongly recommend getting this into a maven standard project format.

If you want help putting this project into a healthy state, layout/build
wise let me know, i could spare a few cycles.

--dave

On 09/29/2015 08:11 PM, Dave Brosius wrote:

> Perhaps i am blind, but i don't see any maven, ant or gradle build
> files. You really need to add these for your code base to be
> accessible to others wanted to uptake it. (Hopefully maven).
>
> --dave
>
> On 09/29/2015 06:55 PM, Gary Gregory wrote:
>> Norman,
>>
>> Hello and welcome to Apache Commons.
>>
>> It's not clear to me why Naomi is better than regular expressions.
>> Pointing
>> to Javadocs is not the best way to get traction.
>>
>> Your project would be better served by having some documentation on your
>> front page with an example driven tutorial.
>>
>> Is Naomi faster than REs?
>>
>> What can I do in Naomi that REs can't do? And vice-versa.
>>
>> Examples of this on your front page would help you at least get folks to
>> consider learning a brand new way of doing things...
>>
>> Gary
>>
>>
>>
>> On Tue, Sep 29, 2015 at 1:06 PM, <[hidden email]> wrote:
>>
>>> My colleague Jeff Rothenberg and I, retirees, have developed an
>>> alternative to
>>> using regular expressions for searching for (and optionally replacing)
>>> patterns in text. We believe it is generally useful to Java
>>> programmers and
>>> would like to contribute it to Apache Commons, where we will
>>> continue to be
>>> active in maintaining the software. You can find the software and
>>> associated
>>> documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.
>>>
>>> Please let us know what further steps we should take to have our
>>> contribution
>>> considered.
>>>
>>> Thank you,
>>>
>>>      Norman Shapiro
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Phil Steitz
In reply to this post by garydgregory
On 9/29/15 3:55 PM, Gary Gregory wrote:

> Norman,
>
> Hello and welcome to Apache Commons.
>
> It's not clear to me why Naomi is better than regular expressions. Pointing
> to Javadocs is not the best way to get traction.
>
> Your project would be better served by having some documentation on your
> front page with an example driven tutorial.
>
> Is Naomi faster than REs?
>
> What can I do in Naomi that REs can't do? And vice-versa.
>
> Examples of this on your front page would help you at least get folks to
> consider learning a brand new way of doing things...

+1
The code in SimpleExamples starts to get to this.  Looks interesting
and powerful.  Either here or on the github readme you should take a
stab at explaining a little more how hard problems using regex get
easier with naomi, illustrated with some simple examples.  Then
maybe with help from community members here, you can develop some
overview / getting started docs that help people get into the code.

Phil

>
> Gary
>
>
>
> On Tue, Sep 29, 2015 at 1:06 PM, <[hidden email]> wrote:
>
>> My colleague Jeff Rothenberg and I, retirees, have developed an
>> alternative to
>> using regular expressions for searching for (and optionally replacing)
>> patterns in text. We believe it is generally useful to Java programmers and
>> would like to contribute it to Apache Commons, where we will continue to be
>> active in maintaining the software. You can find the software and
>> associated
>> documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.
>>
>> Please let us know what further steps we should take to have our
>> contribution
>> considered.
>>
>> Thank you,
>>
>>     Norman Shapiro
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Dave Brosius-2
In reply to this post by Dave Brosius-2
Added a pull request with a first pass at moving all of this to a maven
build. builds and generates javadoc fine. Might need some more fine tuning.



On 09/29/2015 08:27 PM, Dave Brosius wrote:

> Also the source code is not in the proper package structure. The
> class's have packages, but are just dumped directly in src. There is
> javadoc, but just dumped in the main folder. I just dump that, and
> having support building the javadoc from build tools. Setting the
> structure of the project up into some sane will help get people to
> look at it. I'd again strongly recommend getting this into a maven
> standard project format.
>
> If you want help putting this project into a healthy state,
> layout/build wise let me know, i could spare a few cycles.
>
> --dave
>
> On 09/29/2015 08:11 PM, Dave Brosius wrote:
>> Perhaps i am blind, but i don't see any maven, ant or gradle build
>> files. You really need to add these for your code base to be
>> accessible to others wanted to uptake it. (Hopefully maven).
>>
>> --dave
>>
>> On 09/29/2015 06:55 PM, Gary Gregory wrote:
>>> Norman,
>>>
>>> Hello and welcome to Apache Commons.
>>>
>>> It's not clear to me why Naomi is better than regular expressions.
>>> Pointing
>>> to Javadocs is not the best way to get traction.
>>>
>>> Your project would be better served by having some documentation on
>>> your
>>> front page with an example driven tutorial.
>>>
>>> Is Naomi faster than REs?
>>>
>>> What can I do in Naomi that REs can't do? And vice-versa.
>>>
>>> Examples of this on your front page would help you at least get
>>> folks to
>>> consider learning a brand new way of doing things...
>>>
>>> Gary
>>>
>>>
>>>
>>> On Tue, Sep 29, 2015 at 1:06 PM, <[hidden email]> wrote:
>>>
>>>> My colleague Jeff Rothenberg and I, retirees, have developed an
>>>> alternative to
>>>> using regular expressions for searching for (and optionally replacing)
>>>> patterns in text. We believe it is generally useful to Java
>>>> programmers and
>>>> would like to contribute it to Apache Commons, where we will
>>>> continue to be
>>>> active in maintaining the software. You can find the software and
>>>> associated
>>>> documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.
>>>>
>>>> Please let us know what further steps we should take to have our
>>>> contribution
>>>> considered.
>>>>
>>>> Thank you,
>>>>
>>>>      Norman Shapiro
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

jochen-2
In reply to this post by norm-2
Hi, Norman,

On Tue, Sep 29, 2015 at 10:06 PM,  <[hidden email]> wrote:

> My colleague Jeff Rothenberg and I, retirees, have developed an alternative to
> using regular expressions for searching for (and optionally replacing)
> patterns in text.

I admit that I am becoming somewhat cautious by reading about "an
alternative" to one of the best researched and understood parts of the
theory of computer science, namely regular expressions.

We know exactly, how powerful regexes are. And we also know exactly,
what they can't do.

Regarding your work, we don't even know how it would look like.
Because, frankly, docs are quite sparse. And, what I found
(SimpleExamples.java) looks to me more like a different API to
creating regexes, rather than an alternative. And, why bother about
that? I never felt it to be painful to specify a regex in text. Did so
as a Perl programmer, as an Apache programmer (initially with Oro, and
the like) and nowadays as a Java programmer.

Sorry, but unless you come up with compelling reasons, I am -0 to -1.

Jochen

--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

ole ersoy
Hi,

On 09/30/2015 01:44 AM, Jochen Wiedmann wrote:
> Hi, Norman,
>
> On Tue, Sep 29, 2015 at 10:06 PM,  <[hidden email]> wrote:
>
>> My colleague Jeff Rothenberg and I, retirees, have developed an alternative to
>> using regular expressions for searching for (and optionally replacing)
>> patterns in text.
Something that is more fluid and can communicate the semantics of the operation as it is written would be nice.
> I admit that I am becoming somewhat cautious by reading about "an
> alternative"
Agree - most regular expression engines seem to be battled tested fairly well.  I think the complex part of regular expressions is building it and interpreting it, so if something helps with that, thumbs up!

>   to one of the best researched and understood parts of the
> theory of computer science, namely regular expressions.
>
> We know exactly, how powerful regexes are. And we also know exactly,
> what they can't do.
Regular expressions remind me of  punch cards.  If you know what you are doing, and have invested the time to prove that what the expression is doing is what it's supposed to be doing, it's great. However reading, rationalizing, and testing:

|^(?:(?:(?:0?[13578]|1[02])(\/|-|\.)31)\1|(?:(?:0?[13-9]|1[0-2])(\/|-|\.)(?:29|30)\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:0?2(\/|-|\.)29\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:(?:0?[1-9])|(?:1[0-2]))(\/|-|\.)(?:0?[1-9]|1\d|2[0-8])\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$ Can be tricky. So if there's a more fluid way to build and communicate what the above sequence is doing, that would be awesome. |


>
> Regarding your work, we don't even know how it would look like.
Perhaps if some simple examples were posted on the mailing list the developers here could get a better feel for it.

> Because, frankly, docs are quite sparse. And, what I found
> (SimpleExamples.java) looks to me more like a different API to
> creating regexes, rather than an alternative. And, why bother about
> that? I never felt it to be painful to specify a regex in text.
Honestly I feel the pain here.   I have been close to slipping into a coma several times while analysing a regular expression.  We all know programmers make mistakes ( Not me :) ), even in simple situations occasionally, so given how complex some regexs can get...

Cheers,
- Ole

>   Did so
> as a Perl programmer, as an Apache programmer (initially with Oro, and
> the like) and nowadays as a Java programmer.
>
> Sorry, but unless you come up with compelling reasons, I am -0 to -1.
>
> Jochen
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Henri Yandell
In reply to this post by Phil Steitz
On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <[hidden email]> wrote:

> On 9/29/15 3:55 PM, Gary Gregory wrote:
> > Norman,
> >
> > Hello and welcome to Apache Commons.
> >
> > It's not clear to me why Naomi is better than regular expressions.
> Pointing
> > to Javadocs is not the best way to get traction.
> >
> > Your project would be better served by having some documentation on your
> > front page with an example driven tutorial.
> >
> > Is Naomi faster than REs?
> >
> > What can I do in Naomi that REs can't do? And vice-versa.
> >
> > Examples of this on your front page would help you at least get folks to
> > consider learning a brand new way of doing things...
>
> +1
> The code in SimpleExamples starts to get to this.  Looks interesting
> and powerful.  Either here or on the github readme you should take a
> stab at explaining a little more how hard problems using regex get
> easier with naomi, illustrated with some simple examples.  Then
> maybe with help from community members here, you can develop some
> overview / getting started docs that help people get into the code.
>

+1.

Reading SimpleExamples, my summary would be a boilerplate description of
"It replaces the arcane regular expression language with an API". It
reminds me of command line argument parsers. Perl had/has a great regular
expression like command line argument parser, but it was cryptic and you
either loved it or hated it. Then along came Commons CLI, args4j and all
the others, providing a more OO/procedural API instead of its own mini
language. Not as 'powerful' (in that you had to type more), but simpler (in
that you didn't have to learn a new lingo and didn't have to juggle
multiple languages inside one context (a source file)).

I definitely need that user manual. It's hard, with a brain trained on
regular expressions, to read 'Pattern greek3=new CharSequencePattern("?")'
and realize (I think) that it means a literal ? character. It's also the
primary way it'll be successful. You need that educational path that
explains what a ExplicitCharClass is for, rather than randomly clicking on
javadoc :)

There'll also be much debate to be had I suspect. Is "a-e" too complex,
compared to "abcde" or "a","e". Which parts of regex are worth supporting,
vs not. Can I mix bits of regexp with bits of Naomi?   new
ExplicitCharClass("a-eg-p").

Random.... I'd like the idea of varargs for automatic and'ing. ie:

new ExplicitCharClass("a-p", "!f")   [and is a not char class too complex?].

Continuing on my summary, as I peruse the code a little more, I'd go with:

"Build a regular expression via an API, not an arcane language of its own".

I'd love to see that grow to:

"Express regular expressions as objects, or mix and match objects with that
arcane mini language we all love or loathe".

Hen
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

garydgregory
I do not have time to dig into this one ATM but I'd like to give my 2c.

Does this project introduce a new RE-like language or is it an API wrapper
for REs? It sounds like it is both.

A project like this I could see in Commons if the project was split into an
API module and modules for different pattern matching languages, where the
standard Java RE would be the reference example. Naomi (I love the name
BTW, someones wife or daughter?) would be another implementation module.
With both under its belt, the project would be on fairly solid footing
(granted I do not know Naomi). You could even imaging implementations that
would accept a JXPath or a SQL WHERE clause.

If the project is only meant to introduce a new RE-like language, then a
TLP would be probably more appropriate.

2c,
Gary

On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell <[hidden email]> wrote:

> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <[hidden email]>
> wrote:
>
> > On 9/29/15 3:55 PM, Gary Gregory wrote:
> > > Norman,
> > >
> > > Hello and welcome to Apache Commons.
> > >
> > > It's not clear to me why Naomi is better than regular expressions.
> > Pointing
> > > to Javadocs is not the best way to get traction.
> > >
> > > Your project would be better served by having some documentation on
> your
> > > front page with an example driven tutorial.
> > >
> > > Is Naomi faster than REs?
> > >
> > > What can I do in Naomi that REs can't do? And vice-versa.
> > >
> > > Examples of this on your front page would help you at least get folks
> to
> > > consider learning a brand new way of doing things...
> >
> > +1
> > The code in SimpleExamples starts to get to this.  Looks interesting
> > and powerful.  Either here or on the github readme you should take a
> > stab at explaining a little more how hard problems using regex get
> > easier with naomi, illustrated with some simple examples.  Then
> > maybe with help from community members here, you can develop some
> > overview / getting started docs that help people get into the code.
> >
>
> +1.
>
> Reading SimpleExamples, my summary would be a boilerplate description of
> "It replaces the arcane regular expression language with an API". It
> reminds me of command line argument parsers. Perl had/has a great regular
> expression like command line argument parser, but it was cryptic and you
> either loved it or hated it. Then along came Commons CLI, args4j and all
> the others, providing a more OO/procedural API instead of its own mini
> language. Not as 'powerful' (in that you had to type more), but simpler (in
> that you didn't have to learn a new lingo and didn't have to juggle
> multiple languages inside one context (a source file)).
>
> I definitely need that user manual. It's hard, with a brain trained on
> regular expressions, to read 'Pattern greek3=new CharSequencePattern("?")'
> and realize (I think) that it means a literal ? character. It's also the
> primary way it'll be successful. You need that educational path that
> explains what a ExplicitCharClass is for, rather than randomly clicking on
> javadoc :)
>
> There'll also be much debate to be had I suspect. Is "a-e" too complex,
> compared to "abcde" or "a","e". Which parts of regex are worth supporting,
> vs not. Can I mix bits of regexp with bits of Naomi?   new
> ExplicitCharClass("a-eg-p").
>
> Random.... I'd like the idea of varargs for automatic and'ing. ie:
>
> new ExplicitCharClass("a-p", "!f")   [and is a not char class too
> complex?].
>
> Continuing on my summary, as I peruse the code a little more, I'd go with:
>
> "Build a regular expression via an API, not an arcane language of its own".
>
> I'd love to see that grow to:
>
> "Express regular expressions as objects, or mix and match objects with that
> arcane mini language we all love or loathe".
>
> Hen
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Phil Steitz
On 10/2/15 11:46 AM, Gary Gregory wrote:
> I do not have time to dig into this one ATM but I'd like to give my 2c.
>
> Does this project introduce a new RE-like language or is it an API wrapper
> for REs? It sounds like it is both.

It looks to me like what it says it is, which is an alternative to
REs, which IMO is a nice idea.  Less "pattern matching language" and
more objects expressing matching intent.  End result is less
developer thought required to accomplish a common task.  Seems to
fit nicely in Commons to me.

Phil

>
> A project like this I could see in Commons if the project was split into an
> API module and modules for different pattern matching languages, where the
> standard Java RE would be the reference example. Naomi (I love the name
> BTW, someones wife or daughter?) would be another implementation module.
> With both under its belt, the project would be on fairly solid footing
> (granted I do not know Naomi). You could even imaging implementations that
> would accept a JXPath or a SQL WHERE clause.
>
> If the project is only meant to introduce a new RE-like language, then a
> TLP would be probably more appropriate.
>
> 2c,
> Gary
>
> On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell <[hidden email]> wrote:
>
>> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <[hidden email]>
>> wrote:
>>
>>> On 9/29/15 3:55 PM, Gary Gregory wrote:
>>>> Norman,
>>>>
>>>> Hello and welcome to Apache Commons.
>>>>
>>>> It's not clear to me why Naomi is better than regular expressions.
>>> Pointing
>>>> to Javadocs is not the best way to get traction.
>>>>
>>>> Your project would be better served by having some documentation on
>> your
>>>> front page with an example driven tutorial.
>>>>
>>>> Is Naomi faster than REs?
>>>>
>>>> What can I do in Naomi that REs can't do? And vice-versa.
>>>>
>>>> Examples of this on your front page would help you at least get folks
>> to
>>>> consider learning a brand new way of doing things...
>>> +1
>>> The code in SimpleExamples starts to get to this.  Looks interesting
>>> and powerful.  Either here or on the github readme you should take a
>>> stab at explaining a little more how hard problems using regex get
>>> easier with naomi, illustrated with some simple examples.  Then
>>> maybe with help from community members here, you can develop some
>>> overview / getting started docs that help people get into the code.
>>>
>> +1.
>>
>> Reading SimpleExamples, my summary would be a boilerplate description of
>> "It replaces the arcane regular expression language with an API". It
>> reminds me of command line argument parsers. Perl had/has a great regular
>> expression like command line argument parser, but it was cryptic and you
>> either loved it or hated it. Then along came Commons CLI, args4j and all
>> the others, providing a more OO/procedural API instead of its own mini
>> language. Not as 'powerful' (in that you had to type more), but simpler (in
>> that you didn't have to learn a new lingo and didn't have to juggle
>> multiple languages inside one context (a source file)).
>>
>> I definitely need that user manual. It's hard, with a brain trained on
>> regular expressions, to read 'Pattern greek3=new CharSequencePattern("?")'
>> and realize (I think) that it means a literal ? character. It's also the
>> primary way it'll be successful. You need that educational path that
>> explains what a ExplicitCharClass is for, rather than randomly clicking on
>> javadoc :)
>>
>> There'll also be much debate to be had I suspect. Is "a-e" too complex,
>> compared to "abcde" or "a","e". Which parts of regex are worth supporting,
>> vs not. Can I mix bits of regexp with bits of Naomi?   new
>> ExplicitCharClass("a-eg-p").
>>
>> Random.... I'd like the idea of varargs for automatic and'ing. ie:
>>
>> new ExplicitCharClass("a-p", "!f")   [and is a not char class too
>> complex?].
>>
>> Continuing on my summary, as I peruse the code a little more, I'd go with:
>>
>> "Build a regular expression via an API, not an arcane language of its own".
>>
>> I'd love to see that grow to:
>>
>> "Express regular expressions as objects, or mix and match objects with that
>> arcane mini language we all love or loathe".
>>
>> Hen
>>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

garydgregory
Well, a champion can volunteer to shepherd this through our incubator I
suppose, like CommonsRDF, which seems pretty inactive ATM. There is also
the issue of "donate and forget" vs. staying plugged in the community.

I just do not have the extra FOSS cycles to dig into the code ATM to see
what's under the hood.

Gary

On Fri, Oct 2, 2015 at 12:01 PM, Phil Steitz <[hidden email]> wrote:

> On 10/2/15 11:46 AM, Gary Gregory wrote:
> > I do not have time to dig into this one ATM but I'd like to give my 2c.
> >
> > Does this project introduce a new RE-like language or is it an API
> wrapper
> > for REs? It sounds like it is both.
>
> It looks to me like what it says it is, which is an alternative to
> REs, which IMO is a nice idea.  Less "pattern matching language" and
> more objects expressing matching intent.  End result is less
> developer thought required to accomplish a common task.  Seems to
> fit nicely in Commons to me.
>
> Phil
> >
> > A project like this I could see in Commons if the project was split into
> an
> > API module and modules for different pattern matching languages, where
> the
> > standard Java RE would be the reference example. Naomi (I love the name
> > BTW, someones wife or daughter?) would be another implementation module.
> > With both under its belt, the project would be on fairly solid footing
> > (granted I do not know Naomi). You could even imaging implementations
> that
> > would accept a JXPath or a SQL WHERE clause.
> >
> > If the project is only meant to introduce a new RE-like language, then a
> > TLP would be probably more appropriate.
> >
> > 2c,
> > Gary
> >
> > On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell <[hidden email]>
> wrote:
> >
> >> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <[hidden email]>
> >> wrote:
> >>
> >>> On 9/29/15 3:55 PM, Gary Gregory wrote:
> >>>> Norman,
> >>>>
> >>>> Hello and welcome to Apache Commons.
> >>>>
> >>>> It's not clear to me why Naomi is better than regular expressions.
> >>> Pointing
> >>>> to Javadocs is not the best way to get traction.
> >>>>
> >>>> Your project would be better served by having some documentation on
> >> your
> >>>> front page with an example driven tutorial.
> >>>>
> >>>> Is Naomi faster than REs?
> >>>>
> >>>> What can I do in Naomi that REs can't do? And vice-versa.
> >>>>
> >>>> Examples of this on your front page would help you at least get folks
> >> to
> >>>> consider learning a brand new way of doing things...
> >>> +1
> >>> The code in SimpleExamples starts to get to this.  Looks interesting
> >>> and powerful.  Either here or on the github readme you should take a
> >>> stab at explaining a little more how hard problems using regex get
> >>> easier with naomi, illustrated with some simple examples.  Then
> >>> maybe with help from community members here, you can develop some
> >>> overview / getting started docs that help people get into the code.
> >>>
> >> +1.
> >>
> >> Reading SimpleExamples, my summary would be a boilerplate description of
> >> "It replaces the arcane regular expression language with an API". It
> >> reminds me of command line argument parsers. Perl had/has a great
> regular
> >> expression like command line argument parser, but it was cryptic and you
> >> either loved it or hated it. Then along came Commons CLI, args4j and all
> >> the others, providing a more OO/procedural API instead of its own mini
> >> language. Not as 'powerful' (in that you had to type more), but simpler
> (in
> >> that you didn't have to learn a new lingo and didn't have to juggle
> >> multiple languages inside one context (a source file)).
> >>
> >> I definitely need that user manual. It's hard, with a brain trained on
> >> regular expressions, to read 'Pattern greek3=new
> CharSequencePattern("?")'
> >> and realize (I think) that it means a literal ? character. It's also the
> >> primary way it'll be successful. You need that educational path that
> >> explains what a ExplicitCharClass is for, rather than randomly clicking
> on
> >> javadoc :)
> >>
> >> There'll also be much debate to be had I suspect. Is "a-e" too complex,
> >> compared to "abcde" or "a","e". Which parts of regex are worth
> supporting,
> >> vs not. Can I mix bits of regexp with bits of Naomi?   new
> >> ExplicitCharClass("a-eg-p").
> >>
> >> Random.... I'd like the idea of varargs for automatic and'ing. ie:
> >>
> >> new ExplicitCharClass("a-p", "!f")   [and is a not char class too
> >> complex?].
> >>
> >> Continuing on my summary, as I peruse the code a little more, I'd go
> with:
> >>
> >> "Build a regular expression via an API, not an arcane language of its
> own".
> >>
> >> I'd love to see that grow to:
> >>
> >> "Express regular expressions as objects, or mix and match objects with
> that
> >> arcane mini language we all love or loathe".
> >>
> >> Hen
> >>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

norm-2
In reply to this post by garydgregory
My colleague, Jeff Rothenberg, and I are retired computer scientists and are
no strangers to regular expression theory and practice. Both of us have used
regular expressions for decades and have taught many other programmers how to
use them. Stephen Kleene (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
the inventor of regular expressions and I
(https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral students of
Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg used
SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
versions of regular expressions) extensively in his graduate work in
Artificial Intelligence in the late 1960 and early 1970s.

In our experience, although skilled programmers can write regular expressions
that solve a wide range of problems, for all but the simplest tasks regular
expressions quickly become "write only". That is, once they have aged for a
while, no one other than their authors (and, in our experience, often not even
they) can understand them well enough to verify, modify, debug, or maintain
them without considerable effort. Analogous low-level programming formalisms,
such as machine code and assembly language, have been replaced by
higher-level, more readable and modular languages to produce programs that
have proven easier and more cost-effective to debug, verify, maintain, reuse,
and extend.

In a similar fashion, Naomi is a means of "taming" complex regular
expressions, as well as offering an easier alternative for those who are
unfamiliar with them. Naomi makes pattern matching programs more readable,
modular, and therefore verifiable, maintainable, and extensible. Naomi
ultimately generates regular expressions, and it can do everything they can
do, but it provides a higher-level API that uses object-oriented constructs to
define complex, modular, parameterized patterns and subpatterns.

Naomi's advantages over bare regular expressions become apparent only for
larger scale pattern matching tasks. Whereas regular expressions are highly
compact and terse, this virtue becomes a vice for complex patterns. Coupled
with the extensive use of metacharacters and escape sequences, this makes even
moderately complex regular expressions effectively unreadable for all but the
most experienced and practiced regular expression programmers. Newer features
that go beyond the original regular expression formalism--such as namable
groups, built-in names for common character classes, comments, and free white
space--make regular expressions less terse. But their use is not enough to
render complex regular expressions easily readable. These extensions are
analogous to replacing binary machine language by assembly language coding. It
is only necessary to consider a complex problem--such as that of parsing the
e-mail date-time specification of RFC 2822 in src/DateTime.java--to appreciate
the obscurity of regular expressions and to understand Naomi's advantages.



    Norman Shapiro

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Siegfried Goeschl-4
Hi Norman & Jeff,

I skimmed through the email conversation ….

* Personally I really like the idea that retired computer scientists turn to Open Source :-)

* Looking at the GitHub project I indeed see a cultural gap which needs be closed to do meaningful Open Source work

* I try to ignore the fact that you are well-regarded computer scientist and I’m an unknown software developer :-)

Having said that

* no matter if you are joining Apache Commons or just live on GitHub - you need a good introduction to the project (think of unique selling point). Sit down and write a cool Markdown document to get people enthusiastic - only enthusiastic people will use your contributions and maybe participate later on.

* there is a GitHub pull request out there from Dave Brosius - if you are unhappy about it please comment it otherwise merge it with your repo. Ignoring a pull request might be considered impolite :-)

* you need to clean up the project - Maven build (I assume mostly done by Dave Brosius), separate test folder, javadoc, site documentation and code style - and this will take some (all, a lot of ) time and could/will be frustrating since the bar is quite high at Apache Commons (and many other FOSS communities).

Cheers,

Siegfried Goeschl



> On 24 Oct 2015, at 17:14, [hidden email] wrote:
>
> My colleague, Jeff Rothenberg, and I are retired computer scientists and are
> no strangers to regular expression theory and practice. Both of us have used
> regular expressions for decades and have taught many other programmers how to
> use them. Stephen Kleene (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
> the inventor of regular expressions and I
> (https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral students of
> Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg used
> SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
> versions of regular expressions) extensively in his graduate work in
> Artificial Intelligence in the late 1960 and early 1970s.
>
> In our experience, although skilled programmers can write regular expressions
> that solve a wide range of problems, for all but the simplest tasks regular
> expressions quickly become "write only". That is, once they have aged for a
> while, no one other than their authors (and, in our experience, often not even
> they) can understand them well enough to verify, modify, debug, or maintain
> them without considerable effort. Analogous low-level programming formalisms,
> such as machine code and assembly language, have been replaced by
> higher-level, more readable and modular languages to produce programs that
> have proven easier and more cost-effective to debug, verify, maintain, reuse,
> and extend.
>
> In a similar fashion, Naomi is a means of "taming" complex regular
> expressions, as well as offering an easier alternative for those who are
> unfamiliar with them. Naomi makes pattern matching programs more readable,
> modular, and therefore verifiable, maintainable, and extensible. Naomi
> ultimately generates regular expressions, and it can do everything they can
> do, but it provides a higher-level API that uses object-oriented constructs to
> define complex, modular, parameterized patterns and subpatterns.
>
> Naomi's advantages over bare regular expressions become apparent only for
> larger scale pattern matching tasks. Whereas regular expressions are highly
> compact and terse, this virtue becomes a vice for complex patterns. Coupled
> with the extensive use of metacharacters and escape sequences, this makes even
> moderately complex regular expressions effectively unreadable for all but the
> most experienced and practiced regular expression programmers. Newer features
> that go beyond the original regular expression formalism--such as namable
> groups, built-in names for common character classes, comments, and free white
> space--make regular expressions less terse. But their use is not enough to
> render complex regular expressions easily readable. These extensions are
> analogous to replacing binary machine language by assembly language coding. It
> is only necessary to consider a complex problem--such as that of parsing the
> e-mail date-time specification of RFC 2822 in src/DateTime.java--to appreciate
> the obscurity of regular expressions and to understand Naomi's advantages.
>
>
>
>    Norman Shapiro
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Bernd Eckenfels
In reply to this post by norm-2
Hello,

I wish the below cited introduction mail which mentioned how ugly RE for email addresses is, had actually shown a naomi example. Actually for each critisised RE construct.

Besides that, scalability and maintenanceability of regular expressions are an old topic: there are for example things like Grok (in logstash) who make things modular. I guess showing that naomi can replace that as well would help.

Folklore is interesting, but not something I would use to convince people. I read your mail but I dont feel to look up Naomi examples. So until cool syntax constructs are presented it might not really get people excited.

Gruss
Bernd

--
http://bernd.eckenfels.net

-----Original Message-----
From: [hidden email]
To: Gary Gregory <[hidden email]>, Dave Brosius <[hidden email]>, Jochen Wiedmann <[hidden email]>, Commons Developers List <[hidden email]>
Cc: [hidden email], [hidden email]
Sent: Sa., 24 Okt. 2015 5:15 PM
Subject: Re: Proposed Contribution to Apache Commons,

My colleague, Jeff Rothenberg, and I are retired computer scientists and are
no strangers to regular expression theory and practice. Both of us have used
regular expressions for decades and have taught many other programmers how to
use them. Stephen Kleene (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
the inventor of regular expressions and I
(https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral students of
Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg used
SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
versions of regular expressions) extensively in his graduate work in
Artificial Intelligence in the late 1960 and early 1970s.

In our experience, although skilled programmers can write regular expressions
that solve a wide range of problems, for all but the simplest tasks regular
expressions quickly become "write only". That is, once they have aged for a
while, no one other than their authors (and, in our experience, often not even
they) can understand them well enough to verify, modify, debug, or maintain
them without considerable effort. Analogous low-level programming formalisms,
such as machine code and assembly language, have been replaced by
higher-level, more readable and modular languages to produce programs that
have proven easier and more cost-effective to debug, verify, maintain, reuse,
and extend.

In a similar fashion, Naomi is a means of "taming" complex regular
expressions, as well as offering an easier alternative for those who are
unfamiliar with them. Naomi makes pattern matching programs more readable,
modular, and therefore verifiable, maintainable, and extensible. Naomi
ultimately generates regular expressions, and it can do everything they can
do, but it provides a higher-level API that uses object-oriented constructs to
define complex, modular, parameterized patterns and subpatterns.

Naomi's advantages over bare regular expressions become apparent only for
larger scale pattern matching tasks. Whereas regular expressions are highly
compact and terse, this virtue becomes a vice for complex patterns. Coupled
with the extensive use of metacharacters and escape sequences, this makes even
moderately complex regular expressions effectively unreadable for all but the
most experienced and practiced regular expression programmers. Newer features
that go beyond the original regular expression formalism--such as namable
groups, built-in names for common character classes, comments, and free white
space--make regular expressions less terse. But their use is not enough to
render complex regular expressions easily readable. These extensions are
analogous to replacing binary machine language by assembly language coding. It
is only necessary to consider a complex problem--such as that of parsing the
e-mail date-time specification of RFC 2822 in src/DateTime.java--to appreciate
the obscurity of regular expressions and to understand Naomi's advantages.



    Norman Shapiro

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Dave Brosius
In reply to this post by norm-2
Dear My. Shapiro,

Greetings!

Thanks for wanting to share this codebase, and making it available at
github.

I have attempted to cleanup the repository to make it more approachable
for others who want to take a look, including reorganizing the src tree
and adding a proper maven build system. These things would make it
easier to consume.

If you wouldn't mind going to

https://github.com/NormanShapiro/Naomi/pull/1

and looking at the pull request, and if acceptable, pushing the merge
button, that would be great.

Thanks again for you source contributions,

dave.



On 10/24/2015 11:14 AM, [hidden email] wrote:

> My colleague, Jeff Rothenberg, and I are retired computer scientists and are
> no strangers to regular expression theory and practice. Both of us have used
> regular expressions for decades and have taught many other programmers how to
> use them. Stephen Kleene (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
> the inventor of regular expressions and I
> (https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral students of
> Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg used
> SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
> versions of regular expressions) extensively in his graduate work in
> Artificial Intelligence in the late 1960 and early 1970s.
>
> In our experience, although skilled programmers can write regular expressions
> that solve a wide range of problems, for all but the simplest tasks regular
> expressions quickly become "write only". That is, once they have aged for a
> while, no one other than their authors (and, in our experience, often not even
> they) can understand them well enough to verify, modify, debug, or maintain
> them without considerable effort. Analogous low-level programming formalisms,
> such as machine code and assembly language, have been replaced by
> higher-level, more readable and modular languages to produce programs that
> have proven easier and more cost-effective to debug, verify, maintain, reuse,
> and extend.
>
> In a similar fashion, Naomi is a means of "taming" complex regular
> expressions, as well as offering an easier alternative for those who are
> unfamiliar with them. Naomi makes pattern matching programs more readable,
> modular, and therefore verifiable, maintainable, and extensible. Naomi
> ultimately generates regular expressions, and it can do everything they can
> do, but it provides a higher-level API that uses object-oriented constructs to
> define complex, modular, parameterized patterns and subpatterns.
>
> Naomi's advantages over bare regular expressions become apparent only for
> larger scale pattern matching tasks. Whereas regular expressions are highly
> compact and terse, this virtue becomes a vice for complex patterns. Coupled
> with the extensive use of metacharacters and escape sequences, this makes even
> moderately complex regular expressions effectively unreadable for all but the
> most experienced and practiced regular expression programmers. Newer features
> that go beyond the original regular expression formalism--such as namable
> groups, built-in names for common character classes, comments, and free white
> space--make regular expressions less terse. But their use is not enough to
> render complex regular expressions easily readable. These extensions are
> analogous to replacing binary machine language by assembly language coding. It
> is only necessary to consider a complex problem--such as that of parsing the
> e-mail date-time specification of RFC 2822 in src/DateTime.java--to appreciate
> the obscurity of regular expressions and to understand Naomi's advantages.
>
>
>
>      Norman Shapiro
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Pascal Schumacher
Hello everybody,

the pull request was merged, but it is in the "gh-pages" branch not in
"master", so it's not visible by default on the github page.

-Pascal

Am 24.10.2015 um 22:27 schrieb Dave Brosius:

> Dear My. Shapiro,
>
> Greetings!
>
> Thanks for wanting to share this codebase, and making it available at
> github.
>
> I have attempted to cleanup the repository to make it more
> approachable for others who want to take a look, including
> reorganizing the src tree and adding a proper maven build system.
> These things would make it easier to consume.
>
> If you wouldn't mind going to
>
> https://github.com/NormanShapiro/Naomi/pull/1
>
> and looking at the pull request, and if acceptable, pushing the merge
> button, that would be great.
>
> Thanks again for you source contributions,
>
> dave.
>
>
>
> On 10/24/2015 11:14 AM, [hidden email] wrote:
>> My colleague, Jeff Rothenberg, and I are retired computer scientists
>> and are
>> no strangers to regular expression theory and practice. Both of us
>> have used
>> regular expressions for decades and have taught many other
>> programmers how to
>> use them. Stephen Kleene
>> (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
>> the inventor of regular expressions and I
>> (https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral
>> students of
>> Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church).
>> Rothenberg used
>> SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
>> versions of regular expressions) extensively in his graduate work in
>> Artificial Intelligence in the late 1960 and early 1970s.
>>
>> In our experience, although skilled programmers can write regular
>> expressions
>> that solve a wide range of problems, for all but the simplest tasks
>> regular
>> expressions quickly become "write only". That is, once they have aged
>> for a
>> while, no one other than their authors (and, in our experience, often
>> not even
>> they) can understand them well enough to verify, modify, debug, or
>> maintain
>> them without considerable effort. Analogous low-level programming
>> formalisms,
>> such as machine code and assembly language, have been replaced by
>> higher-level, more readable and modular languages to produce programs
>> that
>> have proven easier and more cost-effective to debug, verify,
>> maintain, reuse,
>> and extend.
>>
>> In a similar fashion, Naomi is a means of "taming" complex regular
>> expressions, as well as offering an easier alternative for those who are
>> unfamiliar with them. Naomi makes pattern matching programs more
>> readable,
>> modular, and therefore verifiable, maintainable, and extensible. Naomi
>> ultimately generates regular expressions, and it can do everything
>> they can
>> do, but it provides a higher-level API that uses object-oriented
>> constructs to
>> define complex, modular, parameterized patterns and subpatterns.
>>
>> Naomi's advantages over bare regular expressions become apparent only
>> for
>> larger scale pattern matching tasks. Whereas regular expressions are
>> highly
>> compact and terse, this virtue becomes a vice for complex patterns.
>> Coupled
>> with the extensive use of metacharacters and escape sequences, this
>> makes even
>> moderately complex regular expressions effectively unreadable for all
>> but the
>> most experienced and practiced regular expression programmers. Newer
>> features
>> that go beyond the original regular expression formalism--such as
>> namable
>> groups, built-in names for common character classes, comments, and
>> free white
>> space--make regular expressions less terse. But their use is not
>> enough to
>> render complex regular expressions easily readable. These extensions are
>> analogous to replacing binary machine language by assembly language
>> coding. It
>> is only necessary to consider a complex problem--such as that of
>> parsing the
>> e-mail date-time specification of RFC 2822 in src/DateTime.java--to
>> appreciate
>> the obscurity of regular expressions and to understand Naomi's
>> advantages.
>>
>>
>>
>>      Norman Shapiro
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Dave Brosius-2
Correct.

This was the branch that Mr Shapiro used when he introduced the project
to us, so that's where i did the work. And yes, it is now merged.

My colleague Jeff Rothenberg and I, retirees, have developed an alternative to
using regular expressions for searching for (and optionally replacing)
patterns in text. We believe it is generally useful to Java programmers and
would like to contribute it to Apache Commons, where we will continue to be
active in maintaining the software. You can find the software and associated
documentation athttps://github.com/NormanShapiro/Naomi/tree/gh-pages.

Please let us know what further steps we should take to have our contribution
considered.

Thank you,

     Norman Shapiro



On 10/24/2015 05:44 PM, Pascal Schumacher wrote:

> Hello everybody,
>
> the pull request was merged, but it is in the "gh-pages" branch not in
> "master", so it's not visible by default on the github page.
>
> -Pascal
>
> Am 24.10.2015 um 22:27 schrieb Dave Brosius:
>> Dear My. Shapiro,
>>
>> Greetings!
>>
>> Thanks for wanting to share this codebase, and making it available at
>> github.
>>
>> I have attempted to cleanup the repository to make it more
>> approachable for others who want to take a look, including
>> reorganizing the src tree and adding a proper maven build system.
>> These things would make it easier to consume.
>>
>> If you wouldn't mind going to
>>
>> https://github.com/NormanShapiro/Naomi/pull/1
>>
>> and looking at the pull request, and if acceptable, pushing the merge
>> button, that would be great.
>>
>> Thanks again for you source contributions,
>>
>> dave.
>>
>>
>>
>> On 10/24/2015 11:14 AM, [hidden email] wrote:
>>> My colleague, Jeff Rothenberg, and I are retired computer scientists
>>> and are
>>> no strangers to regular expression theory and practice. Both of us
>>> have used
>>> regular expressions for decades and have taught many other
>>> programmers how to
>>> use them. Stephen Kleene
>>> (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
>>> the inventor of regular expressions and I
>>> (https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral
>>> students of
>>> Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church).
>>> Rothenberg used
>>> SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most
>>> recent
>>> versions of regular expressions) extensively in his graduate work in
>>> Artificial Intelligence in the late 1960 and early 1970s.
>>>
>>> In our experience, although skilled programmers can write regular
>>> expressions
>>> that solve a wide range of problems, for all but the simplest tasks
>>> regular
>>> expressions quickly become "write only". That is, once they have
>>> aged for a
>>> while, no one other than their authors (and, in our experience,
>>> often not even
>>> they) can understand them well enough to verify, modify, debug, or
>>> maintain
>>> them without considerable effort. Analogous low-level programming
>>> formalisms,
>>> such as machine code and assembly language, have been replaced by
>>> higher-level, more readable and modular languages to produce
>>> programs that
>>> have proven easier and more cost-effective to debug, verify,
>>> maintain, reuse,
>>> and extend.
>>>
>>> In a similar fashion, Naomi is a means of "taming" complex regular
>>> expressions, as well as offering an easier alternative for those who
>>> are
>>> unfamiliar with them. Naomi makes pattern matching programs more
>>> readable,
>>> modular, and therefore verifiable, maintainable, and extensible. Naomi
>>> ultimately generates regular expressions, and it can do everything
>>> they can
>>> do, but it provides a higher-level API that uses object-oriented
>>> constructs to
>>> define complex, modular, parameterized patterns and subpatterns.
>>>
>>> Naomi's advantages over bare regular expressions become apparent
>>> only for
>>> larger scale pattern matching tasks. Whereas regular expressions are
>>> highly
>>> compact and terse, this virtue becomes a vice for complex patterns.
>>> Coupled
>>> with the extensive use of metacharacters and escape sequences, this
>>> makes even
>>> moderately complex regular expressions effectively unreadable for
>>> all but the
>>> most experienced and practiced regular expression programmers. Newer
>>> features
>>> that go beyond the original regular expression formalism--such as
>>> namable
>>> groups, built-in names for common character classes, comments, and
>>> free white
>>> space--make regular expressions less terse. But their use is not
>>> enough to
>>> render complex regular expressions easily readable. These extensions
>>> are
>>> analogous to replacing binary machine language by assembly language
>>> coding. It
>>> is only necessary to consider a complex problem--such as that of
>>> parsing the
>>> e-mail date-time specification of RFC 2822 in src/DateTime.java--to
>>> appreciate
>>> the obscurity of regular expressions and to understand Naomi's
>>> advantages.
>>>
>>>
>>>
>>>      Norman Shapiro
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Benson Margulies
gh-pages is the right place for it. You just have to browse to the
correct place on github.io to see it.


On Sat, Oct 24, 2015 at 5:59 PM, Dave Brosius <[hidden email]> wrote:

> Correct.
>
> This was the branch that Mr Shapiro used when he introduced the project to
> us, so that's where i did the work. And yes, it is now merged.
>
> My colleague Jeff Rothenberg and I, retirees, have developed an alternative
> to
> using regular expressions for searching for (and optionally replacing)
> patterns in text. We believe it is generally useful to Java programmers and
> would like to contribute it to Apache Commons, where we will continue to be
> active in maintaining the software. You can find the software and associated
> documentation athttps://github.com/NormanShapiro/Naomi/tree/gh-pages.
>
> Please let us know what further steps we should take to have our
> contribution
> considered.
>
> Thank you,
>
>     Norman Shapiro
>
>
>
> On 10/24/2015 05:44 PM, Pascal Schumacher wrote:
>>
>> Hello everybody,
>>
>> the pull request was merged, but it is in the "gh-pages" branch not in
>> "master", so it's not visible by default on the github page.
>>
>> -Pascal
>>
>> Am 24.10.2015 um 22:27 schrieb Dave Brosius:
>>>
>>> Dear My. Shapiro,
>>>
>>> Greetings!
>>>
>>> Thanks for wanting to share this codebase, and making it available at
>>> github.
>>>
>>> I have attempted to cleanup the repository to make it more approachable
>>> for others who want to take a look, including reorganizing the src tree and
>>> adding a proper maven build system. These things would make it easier to
>>> consume.
>>>
>>> If you wouldn't mind going to
>>>
>>> https://github.com/NormanShapiro/Naomi/pull/1
>>>
>>> and looking at the pull request, and if acceptable, pushing the merge
>>> button, that would be great.
>>>
>>> Thanks again for you source contributions,
>>>
>>> dave.
>>>
>>>
>>>
>>> On 10/24/2015 11:14 AM, [hidden email] wrote:
>>>>
>>>> My colleague, Jeff Rothenberg, and I are retired computer scientists and
>>>> are
>>>> no strangers to regular expression theory and practice. Both of us have
>>>> used
>>>> regular expressions for decades and have taught many other programmers
>>>> how to
>>>> use them. Stephen Kleene
>>>> (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
>>>> the inventor of regular expressions and I
>>>> (https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral
>>>> students of
>>>> Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg
>>>> used
>>>> SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
>>>> versions of regular expressions) extensively in his graduate work in
>>>> Artificial Intelligence in the late 1960 and early 1970s.
>>>>
>>>> In our experience, although skilled programmers can write regular
>>>> expressions
>>>> that solve a wide range of problems, for all but the simplest tasks
>>>> regular
>>>> expressions quickly become "write only". That is, once they have aged
>>>> for a
>>>> while, no one other than their authors (and, in our experience, often
>>>> not even
>>>> they) can understand them well enough to verify, modify, debug, or
>>>> maintain
>>>> them without considerable effort. Analogous low-level programming
>>>> formalisms,
>>>> such as machine code and assembly language, have been replaced by
>>>> higher-level, more readable and modular languages to produce programs
>>>> that
>>>> have proven easier and more cost-effective to debug, verify, maintain,
>>>> reuse,
>>>> and extend.
>>>>
>>>> In a similar fashion, Naomi is a means of "taming" complex regular
>>>> expressions, as well as offering an easier alternative for those who are
>>>> unfamiliar with them. Naomi makes pattern matching programs more
>>>> readable,
>>>> modular, and therefore verifiable, maintainable, and extensible. Naomi
>>>> ultimately generates regular expressions, and it can do everything they
>>>> can
>>>> do, but it provides a higher-level API that uses object-oriented
>>>> constructs to
>>>> define complex, modular, parameterized patterns and subpatterns.
>>>>
>>>> Naomi's advantages over bare regular expressions become apparent only
>>>> for
>>>> larger scale pattern matching tasks. Whereas regular expressions are
>>>> highly
>>>> compact and terse, this virtue becomes a vice for complex patterns.
>>>> Coupled
>>>> with the extensive use of metacharacters and escape sequences, this
>>>> makes even
>>>> moderately complex regular expressions effectively unreadable for all
>>>> but the
>>>> most experienced and practiced regular expression programmers. Newer
>>>> features
>>>> that go beyond the original regular expression formalism--such as
>>>> namable
>>>> groups, built-in names for common character classes, comments, and free
>>>> white
>>>> space--make regular expressions less terse. But their use is not enough
>>>> to
>>>> render complex regular expressions easily readable. These extensions are
>>>> analogous to replacing binary machine language by assembly language
>>>> coding. It
>>>> is only necessary to consider a complex problem--such as that of parsing
>>>> the
>>>> e-mail date-time specification of RFC 2822 in src/DateTime.java--to
>>>> appreciate
>>>> the obscurity of regular expressions and to understand Naomi's
>>>> advantages.
>>>>
>>>>
>>>>
>>>>      Norman Shapiro
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposed Contribution to Apache Commons,

Javin Paul
In reply to this post by Siegfried Goeschl-4
@ Siegfried Goeschl

Having retired computer scientists turn to Open Source is great idea,
nothing can beat experience and having them contributed to Apache or Github
is simply awesome.

On Sun, Oct 25, 2015 at 2:10 AM, Siegfried Goeschl <
[hidden email]> wrote:

> Hi Norman & Jeff,
>
> I skimmed through the email conversation ….
>
> * Personally I really like the idea that retired computer scientists turn
> to Open Source :-)
>
> * Looking at the GitHub project I indeed see a cultural gap which needs be
> closed to do meaningful Open Source work
>
> * I try to ignore the fact that you are well-regarded computer scientist
> and I’m an unknown software developer :-)
>
> Having said that
>
> * no matter if you are joining Apache Commons or just live on GitHub - you
> need a good introduction to the project (think of unique selling point).
> Sit down and write a cool Markdown document to get people enthusiastic -
> only enthusiastic people will use your contributions and maybe participate
> later on.
>
> * there is a GitHub pull request out there from Dave Brosius - if you are
> unhappy about it please comment it otherwise merge it with your repo.
> Ignoring a pull request might be considered impolite :-)
>
> * you need to clean up the project - Maven build (I assume mostly done by
> Dave Brosius), separate test folder, javadoc, site documentation and code
> style - and this will take some (all, a lot of ) time and could/will be
> frustrating since the bar is quite high at Apache Commons (and many other
> FOSS communities).
>
> Cheers,
>
> Siegfried Goeschl
>
>
>
> > On 24 Oct 2015, at 17:14, [hidden email] wrote:
> >
> > My colleague, Jeff Rothenberg, and I are retired computer scientists and
> are
> > no strangers to regular expression theory and practice. Both of us have
> used
> > regular expressions for decades and have taught many other programmers
> how to
> > use them. Stephen Kleene (
> https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
> > the inventor of regular expressions and I
> > (https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral
> students of
> > Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg
> used
> > SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
> > versions of regular expressions) extensively in his graduate work in
> > Artificial Intelligence in the late 1960 and early 1970s.
> >
> > In our experience, although skilled programmers can write regular
> expressions
> > that solve a wide range of problems, for all but the simplest tasks
> regular
> > expressions quickly become "write only". That is, once they have aged
> for a
> > while, no one other than their authors (and, in our experience, often
> not even
> > they) can understand them well enough to verify, modify, debug, or
> maintain
> > them without considerable effort. Analogous low-level programming
> formalisms,
> > such as machine code and assembly language, have been replaced by
> > higher-level, more readable and modular languages to produce programs
> that
> > have proven easier and more cost-effective to debug, verify, maintain,
> reuse,
> > and extend.
> >
> > In a similar fashion, Naomi is a means of "taming" complex regular
> > expressions, as well as offering an easier alternative for those who are
> > unfamiliar with them. Naomi makes pattern matching programs more
> readable,
> > modular, and therefore verifiable, maintainable, and extensible. Naomi
> > ultimately generates regular expressions, and it can do everything they
> can
> > do, but it provides a higher-level API that uses object-oriented
> constructs to
> > define complex, modular, parameterized patterns and subpatterns.
> >
> > Naomi's advantages over bare regular expressions become apparent only for
> > larger scale pattern matching tasks. Whereas regular expressions are
> highly
> > compact and terse, this virtue becomes a vice for complex patterns.
> Coupled
> > with the extensive use of metacharacters and escape sequences, this
> makes even
> > moderately complex regular expressions effectively unreadable for all
> but the
> > most experienced and practiced regular expression programmers. Newer
> features
> > that go beyond the original regular expression formalism--such as namable
> > groups, built-in names for common character classes, comments, and free
> white
> > space--make regular expressions less terse. But their use is not enough
> to
> > render complex regular expressions easily readable. These extensions are
> > analogous to replacing binary machine language by assembly language
> coding. It
> > is only necessary to consider a complex problem--such as that of parsing
> the
> > e-mail date-time specification of RFC 2822 in src/DateTime.java--to
> appreciate
> > the obscurity of regular expressions and to understand Naomi's
> advantages.
> >
> >
> >
> >    Norman Shapiro
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thanks
Javin
http://javarevisited.blogspot.com/
Twitter : https://twitter.com/javinpaul
blog : http://java67.blogspot.com
blog : http://savingsfunda.blogspot.com
12