commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: Proposed Contribution to Apache Commons,
Date Sun, 25 Oct 2015 22:58:28 GMT
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.

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


Mime
View raw message