[rescue] Mozilla Firefox
pat at computer-refuge.org
Thu Apr 22 22:12:33 CDT 2004
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
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.
Purdue University ITAP/RCS --- http://www.itap.purdue.edu/rcs/
The Computer Refuge --- http://computer-refuge.org
More information about the rescue