[rescue] Mozilla Firefox

[Patrick Finnegan]

On Thursday 22 April 2004 21:00, Dave McGuire wrote:
> On Apr 22, 2004, at 12:56 PM, Peter Corlett wrote:
> > Not entirely fair. I mostly got interested in OOP when I could see
> > the relationship between the code and the raw hardware.
>
>    Eh...I'd sure like to hear more about this.  Especially something
> like, what instruction on a SPARC, for example, is involved in
> "new"-ing an object. ;)

Or what instruction is involved in this C code:

struct mooCow *cow= malloc(sizeof(struct mooCow));
initmooCow(cow, ChocolateMilk, Noisy, ExtraMethane, Spotted);

Ok, I guess there's some difference, but it's not that far off unless 
you're talking about dynamic typing, playing with casts, and such.

> >  In C++, you lose some by
> > having an extra layer of indirection sometimes, you win by having a
> > Big Bastard Optimiser on the job.
>
>    Again, band-aiding to massage something into an architecture in
> which it does not fit.

I'm not sure I completely agree with that description of C++.  I 
understand what you're saying, but the point of the programming 
language is to make it easier to write reusable code, which isn't tied 
strictly to the architecture implementation.  At least, that's my take 
on it.  Of course, have no clue about implementation helps make you a 
bad coder as well.  You should be aware of it, but shouldn't be 
directly tied to it.

Still, I hate to write code in OO languages, and prefer C or assembly 
for things too complicated for a 10-line borne shell (or bash) script.

> > Sometimes people take the idea of code reuse a little *too* far,
> > and write
> > code that is "reusable", but not actually usable for anything.
>
>    Well that's a big part of the problem...it *is* usable, if you
> have a 2+GHz processor and 1+GB of RAM!  And since a lot of these
> "programmers" have never done any other types of projects or worked
> on any other type of system, they think it's normal for a
> weather-display widget to eat 23MB.

I think you're overstating it a bit, but I agree with you 1000% on this.  
I am genuinely annoyed by people that use scripting languages (be it 
Python, Perl, or my least favorite, Tcl) to do things that are better 
suited to C (basically anything that's not a text processor).

At $work, we have a fair number of people (professors/researchers) that 
have code written in MATLAB (a popular matrix programming language that 
is Java meets borne shell).  They're trying to do Useful Work in it.  
Another part of the group I work for does "applications" work, and 
helps users with writing the applications, if the user wants it.  

It turns out that this was the time their code took to run (same basic 
program/data/machine/etc):

Matlab: 12 hours
C: 	30 minutes

That's a factor of 24 speedup!!  And these are college professors that 
are writing code in $crappy_slow_language, not some 1337 kid that 
hasn't learned enough yet.  

I think I'd blame two things... they start with something simple, like 
MATLAB, get a proof of concept/prototype, and instead of moving it to a 
new language, and getting whatever help they need, the decide they 
can't wait, and just keep adding and revising the code.

Don't get me wrong, MATLAB can be a decent language.  It's a great 
teaching tool, where you want to teach people about math-related things 
with a minimal amount of programming knowledge.  It works well as a 
scripted graphing calculator.  However, it ROYALLY sucks for doing any 
sort of Real Work.

And I apply that comment (in general) to Java, and programming using 
abstraction layer on top of abstraction layer.

KDE is a good example of this.  I wrote a simple network traffic grapher 
that watches the packet count from ifconfig, and draws a nice pretty 
graph.  First implementation, I used KDE, and ended up with a couple of 
MB exececutable... maybe as much as 10MB.  Converting it to using Qt 
only, the size dropped down to a couple hundred KB.  IMHO, Qt is a 
pretty darn nice graphics toolkit, which is cross-platform, relatively 
small and quick.  KDE on the other hand, adds an unbelievable amount of 
bloat to that.  In fact I think the code was basically the same between 
both (using Qt widgets) with the exception of using KApplication 
instead of the Qt equivalent in the first version.

I guess the moral of the story is people should take a few minutes and 
say "why do we want to do it this way, when this other way is 
faster/more efficient" when they start writing the code.  Small 
changes, like what X widget toolket you use can make AMAZING impacts on 
what you get in the end.

Pat
-- 
Purdue University ITAP/RCS        ---  http://www.itap.purdue.edu/rcs/
The Computer Refuge               ---  http://computer-refuge.org