Re: OT: Why is C so popular?
Ron Johnson wrote:
Speed is over-rated.
Lets take my MUA, Evolution, for example. It's not processor
intensive. Why couldn't it be written in Python?
Ok, I refrained from the last Evolution comment about "if CLI program X
had menus, I'd drop Evolution", but "It's not processor intensive," that
I can't let go. The copy of Evolution (1.0.3-6, not up-to-date so maybe
they've optimized it) I have on my K6-2/450 makes it cry when it starts
up. It's not as bad as say, watching 2000 boot, but being able to read
each item initialize 'loading bla, loading more bla, loading mail...' or
fall asleep as it starts up, that's a little slow. Reminds me of
starting an old copy of StarOffice on that machine.
Oh well. Mozilla keeps me happy for the moment. Good thing Evolution is
there for others who like/need it. Maybe the day will come when I'll use
it again because I need the other features integrated together with my
mail program or I'll get sick of something in Mozilla mail. This version
doesn't have a spell checker (I could sorely use one) and though it
does many things I need it for very well, It would be cool if it would
do a few other things a little better, like post attributes and showing
the plain text version of everything if I'm composing in plain text.
So many potential bugs related to pointers and null-terminated
strings would be eliminated. The SLOC count would be lowered, and
that means a lower bug count and quicker development. (Many studies
have proved that bug count and speed are soley related to SLOC, no
matter what language is used.)
For the necessary GUI stuff, use the existing wrappers python-gtk2
and python-gnome2.
To keep this sorta on topic, I guess I'll ponder on why it wasn't and if
it couldn't be written in python.
Maybe the group who developed it wasn't enlightened in the ways of the
snake. Maybe they were scared of not having braces to hang on to. It
looks like they coded a multi-threaded CORBA/Glade/GDK using C. Maybe
they chose C because there was good documentation on using
CORBA/Glade/GDK for C, or more likely they were seasoned C hackers.
I don't know the specifics on how performance would differ if it was
written in language python or some other script/interp language. If it
just altered the initial start-up time by a second or three I wouldn't
care. If made the software seem unresponsive then I would care. The fact
that Evolution is in C doesn't make it snappy on my 450.
I don't worry about what something's written in until I look at either
extending it or hoping to help fix a bug. I guess if I saw that the
program I wanted to help fix was written in COBOL (no offense, just not
my cup of tea) then I'd skip submitting a patch and just complain about
the bug or find another program. If I don't have to change the source to
extend it, but can use a scripting language I'm familiar with then
again I don't care if the source is from COBOL.
I thought it was cool that a lot of the redhat-config-* programs were
python/tk(?). That got me looking at python but my steam ran out. Maybe
another day. On the other hand some of those tools on RH7.3 have bugs
that are still there. Odd that some RH using Python gurus didn't get a
patch submitted and working within a month of 7.3's release if it is so
easy to debug. Then again maybe the bug is in the windowing toolkit (I
dont remember if it's tk or something else) and not the Python code, or
maybe they submitted the patch and RH didn't take the time to implement it.
There is hopefully no reason why you couldn't write a program like
Evolution in Python. Maybe one is already out there or will show up next
month. If it kicks butt because new features can be added faster and
bugs squished quicker due to the superiority of the language and it's
ability to help people think about the algorythms and not the code then
more power and masses to Python which would then mean more and better
programs in Debian with less effort. Sounds good to me.
I look forward to seeing a slew of these super programs. I've played a
coupe of Python powered games on this system, an Athlon 1800+ running
unstable. SolarWolf plays fairly well. Much better than Shockwave games
on a K6-2/450, but shockwave games on this system are snappy. Sometimes
there is a hesitation responding to my input playing SolarWolf, but so
does defendguin which uses SDL and is probably in C.
Until then
int main(void)
{
...[cut]...
if ( C != NULL && there_is_c_documentation) {
if ( (size = snprintf(msg, 127, "I will code in C ;)") == -1 ) {
perror("snprintf()");
exit(EXIT_FAILURE);
}
if ( (size == send(socket, msg, size, 0)) == -1 ) {
perror("send()");
exit(EXIT_FAILURE);
}
} else {
if ( (size = snprintf(msg, 127, "Crum! I hope I've learned
something better by now...")) == -1 ) {
perror("snprintf()");
exit(EXIT_FAILURE);
}
if ( (size = send(socket, msg, size,0)) == -1 ) {
perror("send()");
exit(EXIT_FAILURE);
}
}
exit(EXIT_SUCCESS);
}
Sorry, I couldn't help writing a little something with a lot of braces
for you Python coders. I look forward to lots of cool pyapps.
Jacob
Reply to: