|
![](/i/fill.gif) |
clipka wrote:
> Yeah, but what is the *current* aim?
From *my* experience, the current aim is to dick around with it for fun so
it takes several weeks of intense concentration and trial-and-error to get
each new point release to even compile.
> 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).
Exactly. My point was that nobody rewrites a chunk of SQL in C. They pull
the data and manipulate it in C, which is rather different from cracking
open the RDBMS and modifying it to add their query as a SQL primitive. :-)
> And in general, serious languages tend to have *some* generic interface to
> libraries written in C
Sure, but that's because C is close to assembler. Anything with a reasonable
calling convention can do that, assuming the CPU is designed to run C. Most
of them also have some generic interface to Windows COM as well. I'm not
sure what the point is. :-)
LISP machines, Smalltalk machines, and FORTH machines all lack generic
interfaces 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).
Precisely my point. The farther from C your language gets, the less likely
you can easily invoke C.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
![](/i/fill.gif) |