You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Miles Elam <mi...@geekspeak.org> on 2002/12/19 05:24:21 UTC

[OT] Rant about bashing academia

Andrew C. Oliver wrote:

> The fourth choice:
>
> - convince others that it is a problem, build a consensus and drive 
> action towards that effect.  You keep telling me love it or leave it. 
> Maybe one day I'll leave it Stefano.  I haven't given up yet.  I just 
> have a lot of stuff to sort through before I can do it myself. 

Convince others that it is a problem?  This statement carries the 
implication that the developers do not currently know how long it 
takes.  It assumes that they have made the decision to completely ignore 
speed.  I find that hard to believe and frankly find it hard to believe 
that you believe it too.

>> Can Forrest be faster than it is today? sure. I think that with 
>> tweaking the sitemap and the component pools we can gain a lot of 
>> speed. Also I'm not sure how 'cache friendly' the Cocoon CLI is (that 
>> is another source of major speed gain).
>
> That is my concern.  Its not that usable in many cases at its current 
> speed. 

Ever heard the quote "premature optimization is the root of all evil?"  
You code for correctness first and then optimize.  Doing the opposite is 
a sure recipe for incorrect (and incorrectable) behavior.

>> Con Forrest be faster than Anakia? hardly. Anakia doesn't even parse 
>> the XML. It's a text generation system. It's designed for command 
>> line. It's designed for unstructured data. It's designed for small 
>> sites. It's designed with no idea of SoC.
>
> Okay this is the practitioner versus the achedemic here.  I don't care 
> about SoC if SoC means my docs come out in 10 minutes versus 1.  

Even if in the one minute case, the docs come out wrong?  Even if in the 
one minute case, maintainability suffers?  People are lazy.  Programmers 
doubly so.  If the design does not enforce the intent, the intent is lost.

Practitioners brought about browser feature-creep escalation and tag 
soup that is the web today.  Academic rigor brought us web standards.  
If you want the practitioner approach, use Anakia.  I assume that it 
would serve you well.  If you want something that works more with 
context and clear guidelines of role in documentation generator, it 
might benefit looking at how Forrest tries to solve the problem.

>> In short, they are two different things that happen to have partial 
>> functionality overlap.
>
> Exactly what practical thing does forrest do that Anakia doesn't other 
> than PDF generation? 

SoC.  Just because it holds no value in your opinion does not mean that 
it holds no value.

>> Andy, if you like Anakia more because it fits your needs, use that!
>
> I usually do.   I hope one day not to have to. 

Why not?  If SoC does not matter to you as much as speed, why on earth 
would you want to use Forrest?  What is it about Anakia that you find so 
offensive that Forrest must be your saviour?

>> And then complain to them about the fact that it doesn't this or 
>> that, even if it *doesn't* very quickly :-P
>
> Sorry to burn your holy books... But I just want it to work fast 
> enough to use. 

I hope everyone recognizes that these same comments were used to deride 
Mozilla two years ago.  Their first priority was to correctness.  People 
told them that they were crazy.  They didn't care about "academic" 
correctness;  They wanted it fast *now*.  They said the object model was 
useless overhead.  They said that if the program was slow now -- despite 
repeated attempts to explain the utility of good interfaces and 
processes before implementation optimizations -- it would always be 
slow.  I would like everyone to take a good look at the difference 
between M16 and v1.2.1 of Mozilla.

I would like everyone to reflect on what Mozilla would be like if they 
had gone for the quick speed fixes instead of concentrating on good, 
maintainable (!!!) design first.  Where would we be?  I'll tell you 
where we'd be.  We'd have another semi-standards-complaint browser like 
IE that made developers bend over backwards to get pages to work but 
without the benefit of W3C standards pages to give sanity checks as to 
what "correct behavior" was.  We'd have another browser that worked on a 
handful of platforms, but because of resource constraints, completely 
ignore others.  Unlike IE and Opera, the page I make on Linux renders 
the same on Mac, Windows, Solaris, etc.  iCab is plenty fast, but don't 
expect standards out of it anytime soon.  I would expect Mozilla to 
speed up at a greater pace.

I don't know about you, but I want nothing to do with the days of 
specifying both marginheight/marginwidth and leftmargin/topmargin, 
spacer gifs, tables for layout, the blink tag, the font tag, the morass 
of conflicting frames syntax, differing font sizes for Macs vs. PCs.  
The practicioners aren't doing anything useful in this regard.  It's the 
academics who are trying to find a way out of this mess while the 
practicioners bitch about all of the shit code they have to completely 
rewrite because they had no design cycle.

Where would many Open Source projects be if the Mozilla group hadn't 
spent the time to create Bugzilla in the early stages of their 
development cycle?  Tinderbox?  Rhino?

Contrary to popular belief, good software takes a long time.  How long 
had Linux been around before it became a truly functional system?  How 
long has UNIX been around?  How long has the Apache web server been 
around, making fixes, adding features, etc.?  And you want Forrest to do 
everything planned right now, this minute, and with excellent performance?

I am afraid your expectations simply are not reasonable.

- Miles

P.S.  I am 28 years old and do not have a degree.  When I started 
college ten years ago, I was a literature major.  I am by no means some 
stifled computer science academic who hasn't seen the real world and 
business.  What I have seen is project after project that was crushed 
under its own weight because there wasn't sufficient discipline when the 
project was started...because of speed (performance and time to release) 
concerns.  Silicon Valley is littered with the corpses of companies full 
of practicioners.  One of the saving graces of Open Source is the 
liberty to spend the time to get it right.

"Is the Dark Side stronger?"
"No!  Quicker.  Easier.  More seductive."