@ 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
