Darren New <dne### [at] sanrrcom> wrote:
> > For a project like the Linux kernel that is aimed at high portability,
>
> Well, no.  The Linux kernel wasn't started aimed at high portability. Just
> the opposite, really.

Yeah, but what is the *current* aim?


> > Another reason is speed, of course, but just like with Assembler it could be
> > argued that only the most heavily-used portions of a project should resort to C
> > for speed these days.
>
> Mmmm.... Debatable. :-)  It really depends on the rest of the system. If
> you're writing in some language fundamentally different from C, you might
> spend more time translating into C data structures than you do to run it.
> Nobody says "Wow, this SQL query is really slow. Let's rewrite it in C."

I said, it *could* be argued. And BTW, *some* SQL queries are indeed easier to
do by just pumping the data into a C program and doing the filtering & sortng
manually (though generally you'd first have a look to see if you can somehow
improve performance by tweaking the DB, rephrasing the query, or the like).

And in general, serious languages tend to have *some* generic interface to
libraries written in C (though then again, some of these interfaces seem to be
pathological, as with Perl for instance; seen a colleague once struggling to
pass a NULL pointer or some such into a C API function).

Post a reply to this message