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
