Front page | perl.bootstrap |
Postings from July 2000
> > Reusing a compiler parser on that is likely to be a challenge :-) > > > > I don't have a problem with wanting to make it more possible to handle Perl > > in this sort of context - but don't assume that splitting out the parser is > > a "magic bullet". > > That's exactly why I'm in favor of having a well-defined grammer that lets > you write your own parser if you think you need to. > > > And I don't think > > that redesigning Perl's syntax to be easily parseable is going to get > > anywhere - the result just wouldn't be Perl, in some very fundamental ways. > > I don't believe that has to be the case. I'm looking over these comments and keep thinking that while issues like this have contributed to the quirkiness in Perl that we all know and love, it's also contributed to Perl's rather cool acceptance in some areas. The best Perl IDEs that I have seen have been nothing more than glorified text editors with a bit of debugger support thrown in. This is due, in part, to the "only Perl can understand Perl" issue. While I know that some elitists will sneer at the idea of making Perl easier to parse, the fact remains that many companies who need a programming solution may choose a language other than Perl because the other languages don't have issues like this and are easier to bring new coders up to speed. I have a friend of mine who was practically in tears yesterday because his company chose Python over Perl -- and my friend agreed because it was the right decision for what they were doing. I absolutely love Perl, but if it keeps blazing its own trail, it may realize why others aren't on it.