On Sun, Oct 25, 2015 at 3:58 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 10/25/15 3:53 PM, Gary Gregory wrote: > > Let's see, would we run this through the Apache Incubator or could we > > simply run it through our Commons Sandbox and then up to Commons itself? > I think we can just start in the sandbox, following the Incubator IP > clearance process as we have done before. I volunteered above to > manage the IP clearance process and VOTE to accept. It seems like > there is some interest here in working on it, so that qualifies for > the Sandbox, IMO. > Roger that, champion away Phil! :-) Gary > > Phil > > > > Gayr > > > > On Sun, Oct 25, 2015 at 12:06 AM, Javin Paul <savingfu...@gmail.com> > wrote: > > > >> @ 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 < > >> siegfried.goes...@it20one.com> 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, n...@dad.org 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: dev-unsubscr...@commons.apache.org > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >> > >> -- > >> Thanks > >> Javin > >> http://javarevisited.blogspot.com/ > >> Twitter : https://twitter.com/javinpaul > >> blog : http://java67.blogspot.com > >> blog : http://savingsfunda.blogspot.com > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 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
