Marduk Bolaños wrote on 08/14/2015 10:06 PM:
Since Racket is a compiled
language, I thought that perhaps it would be possible to compile these
packages as shared libraries and then (ideally automatically) generate
bindings for the desired language.
I think I understand your message, and am sympathetic.
It's tricky. There are lots of ways to "interoperate" between
languages, but once you get into high-level languages (Racket, Java,
Python, JavaScript, etc.), the C calling-convention native code way you
might be thinking of doesn't necessarily work well. We can make it
work, as needed, but sometimes making it work very smoothly and
efficiently for all cases, like you might imagine, is infeasible or
simply a low priority. (I started to get into details here on all the
ways you can interoperate, but it's too big a topic for a general email.)
Also, FWIW, consider that, even if today you had *everything* using the
native code interoperation, we might be in trouble when we find we have
to write code that sits on the GPU (i.e., a different native
architecture) at the same time as the code we're reusing, or use some
"safe" "big data" compute server model, or whatever comes next. Maybe
higher-level languages that aren't so easily mapped to a particular
model of native code put us in a better position to smooth that transition.
It really bothers me that the current status of scientific software
engineering is such that there are several implementations of plotting
libraries, computer algebra systems, numerical routines libraries,
etc. all doing mostly the same things but differing in the language in
which they are written.
Note that I have nothing against diversity, but it seems to me that
there is too much reinventing the wheel.
Agreed, there is a lot of reinventing the wheel in computing in general,
and rough interoperation in computing in general. This is not unique to
computing. There's no single reason for it, but any of a large number
of reasons, varying per instance. Sometimes overwhelmingly good
reasons, usually trade-offs, sometimes no good reason I can see.
Don't get me started on some of the travesties that have happened
relatively recently in CS -- in which accidents, impropriety, and just
plain ignorance led to big steps backwards in the tools that we CS
people use for thinking and building. It's not only *non*-CS scientists
who feel the pain of IT wheel-reinventing. :)
You mentioned Racket plot. I know there has been interest in doing more
numerical things in Racket. I don't know what the latest Racket plans
are, but I assume that there are good reasons for whatever is being, er,
plotted.
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
