commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Proposed Contribution to Apache Commons,
Date Sun, 25 Oct 2015 23:05:01 GMT
On Sun, Oct 25, 2015 at 3:58 PM, Phil Steitz <phil.steitz@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 <savingfunda@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.goeschl@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, norm@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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message