Front page | perl.perl5.porters |
Postings from September 1999
I've actually been following SDF for the past 4 years now and have had several correspondences with Ian during that time. So I'm more than just a little familiar with SDF though still by no means an expert). On Tue, Sep 28, 1999 at 09:06:02AM -0700, Russ Allbery wrote: > My understanding is that SDF is attempting to solve a larger problem and > is therefore semantically richer This part is very much is correct. > sufficiently so that it's no longer "plain." This part is very much incorrect however. SDF is about as "plain" as it gets. IMHO its much plainer than POD *most* of the time. The only time it isn't is for the more sophisticated/advanced cases where POD really can't even do what you require. There are a few areas where SDF's markup looks sufficiently different from PODs as to make each camp think the other's markup is the less plain of the two; but those are really six of one and half dozen of the other. For the really ultra simple stuff, SDF is at least as plain, if not more so. For the medium stuff its about the same, sometimes a little bit worse (but only a little, and its very consistent in its syntax). And for the advanced stuff SDF starts looking not-so-plain, but still way better than POD would in those rare cases where its even capable of doing the same things. > I'm not sure if such a merger would be in the best interests of > either POD or SDF. I am quite sure that it most definitely would be. The main issue here is the size of the SDF user-docs and command-set. We don't want the next generation of "perlpod" to be a 20-50 page monstrosity. The bare basics should be able to be described in about 5 pages and can refer to the more detailed reference docs for other stuff. Even so, that would still add a substantial amount of documentation to the distributed result (and maybe twice as many executables as the current set of pod2xxx scripts). However, I think the stylistic differences between the two (POD vs SDF) have been two overwhelming to overcome in the past. SDFers and PODophiles have grown into being used to certain things in certain ways that are each simple in their own right, but each one appears as anathema to the other. So I don't see SDF replacing POD anytime soon unless either (1) SDF gives in and becomes more limited and more POD-like; or (2) the current markup for both SDF and POD are tossed and something completely new takes their place ina collaborative and cooperative fashion that builds on the strengths and lessons learned from both, without being overly biased in each others idiosyncracies of old. As author of Pod::Parser, I'd be happy to work with Ian if I thought either of these were readily achievable. Call me a pessimist, I'm not so sure that they are. (I'd be happy to be proven wrong here - particularly on (2) if there can be a "backward compatibility" mode that accepts the old markup format but deprecates it in favor of the new one). Just my $0.02 of course. I'm sure many perl5-porters would be happy to vehemently disagree with me about the merits of SDF over POD ;-) Cheers! -- Brad Appleton <bradapp@enteract.com> http://www.enteract.com/~bradapp/ "And miles to go before I sleep." -- Robert FrostThread Previous | Thread Next