Using the draw and plot packages with other languages

[Marduk Bolaños]

Dear all,

As everybody knows, Racket's plot library is feature-rich and produces
beautiful output. The draw library is also great for generating
diagrams. I prefer functional-style drawing over LaTeX packages.

What I would like to do is to be able to use these libraries in
Maxima, Julia and other scientific computing environments.

If I understand correctly, the plot package relies on the draw
package, which in turn uses cairo. 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.

Given that a lot of time and expertise is involved in the development
of the tools used in the scientific computing workflow, I believe that
in order to maximize the profit and minimize the duplication of
effort, such tools should be able to interoperate smoothly.

In my view, the core algorithms should be written once in a compiled
language and then all that should be needed to use them in your
prefered language is to generate the bindings.

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.

I look forward to your comments.

Best,
Marduk

[Matthew Butterick]

I don't do scientific computing, but it seems your question is to some degree about economic incentives. When you say "maximize the profit," whose profit are you referring to? When you say "minimize duplication of effort," whose labor costs are you referring to? And if this work is so valuable to the profit-taker / cost-avoider, why aren't they already investing in a solution?

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Marduk Bolaños]

> When you say "maximize the profit," whose profit are you referring to?

What I mean is that software that could be useful in several contexts,
like a plotting library, should enable the possibility of pluging it in
to a larger software project. That way, several projects would
benefit/profit from the effort and expertise of the authors of the
software library.

> When you say "minimize duplication of effort," whose labor costs are
> you referring to?

People/projects needing the functionality provided by the library would
not have to implement it, thus avoiding a duplication of effort.

> And if this work is so valuable to the profit-taker / cost-avoider,
> why aren't they already investing in a solution?

I do not understand why are you being so defensive/aggressive. My
understanding is that most people in the Racket community are academics
and so are many scientists. As is well known, most scientists are not
paid for writing software, we do not have time to do it and most of us
lack the training. Therefore, what we try to do is to use the tools that
are available.

I came to this forum asking for advice on integrating Racket libraries
with free software projects, not on using them for commercial purposes.
I hope that I can receive a better response than "Why don't you write
your own plotting library?".

Best,
Marduk

[Matthias Felleisen]

Hi --

nobody here is accusing you of anything. It's just that we are
not used to the words "profit" and "maximize profit" on this
mailing list.

In general I agree with you that it would be wonderful if we
could easily integrate tools across programming languages.
Sadly, I think that this is neither technically easy nor socially
desirable:

-- Each language comes with invariants and assumptions that
govern the relationship between compiler and run-time system.
Gluing compiled code isn't as simple as linking pieces of code.

-- As you say, scientists aren't paid to write code. As you may
realize, programming language designers are not paid to support
scientists. There are many kinds of users, and they all deserve
support.

One more thing you should appreciate about our situation.
A long time ago scientists used computer scientists
as their scribes. They governed the funding agencies (and still
do to a lesser extent), they didn't respect computer science as
an independent discipline ("fancy paper and pencil") and told
us what to do. Fortran I. Fortran II. Fortran III. Fortran IV. ...
... Fortran XIIIX (which uses this strange Java syntax). They got
what they asked for without listening to anyone who disagreed.
Now the chicken has flown the coop (or something like that),
and it's too late for now

Having said that, my hunch is that if you conducted the necessary
research, people would eventually appreciate what you are doing
but it would still take a while

Good luck and I am looking forward to your next technical post

-- Matthias

[Neil Van Dyke]

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.

[Marduk Bolaños]

Dear Matthias,

Thank you for your thoughtful response.

> we are not used to the words "profit" and "maximize profit" on this
> mailing list.

Most people are used to linking profit with money but it has a much
broader meaning.

> Sadly, I think that this is neither technically easy nor socially
> desirable:

> Gluing compiled code isn't as simple as linking pieces of code

Thanks for pointing this out. I am slowly learning.

> As you may realize, programming language designers are not paid to
> support scientists. There are many kinds of users, and they all
> deserve support.

I absolutely agree. However, I believe that making a piece of code more
versatile is beneficial to all users, not only scientists. I fail to see
why you say that it is not socially desirable. I am really concerned
about this remark.

> A long time ago scientists used computer scientists as their scribes

> and told us what to do. They got what they asked for without listening

> to anyone who disagreed. Now the chicken has flown the coop (or
> something like that), and it's too late for now

I agree that Fortran is a terrible language. Now that I am learning a
little Lisp I realize that scientists have been foolish ignoring it.

It is good to live in a time when computer scientists are in control of
their area of expertise and young scientists, like myself, are trying to
learn the languages, design patterns and tools that have been carefully
developed by knowledgeable people.

However, some of the tools needed by scientists are also useful for
other purposes and it is better to let the experts develop them. As a
scientist, I would rather spend my time writing software for research
purposes than for a general audience.

> if you conducted the necessary research, people would eventually
> appreciate what you are doing but it would still take a while

I am slowly learning what I think is necessary (HtDP is in my reading
list). I know that change is difficult. For now I need to learn or
develop the tools with which I feel more comfortable and that make me
more productive.

Coming back to my original question. What is your advice for using
Racket's draw and plot in other programs?

Cheers,
Marduk

[Marduk Bolaños]

Dear Neil,

Thank you very much for your thoughtful reply and your understanding.

> There are lots of ways to "interoperate" between languages, but once

> you get into high-level languages the C calling-convention native code

> way you might be thinking of doesn't necessarily work well.

I am really interested in this topic. Many scientists write libraries in
Matlab and Mathematica and I find this very unfortunate. Not only do
they require you to buy a license for this software but it is also
difficult to use them in your favourite language/environment. Therefore,
I am thinking of writing my libraries in a compiled language in order to
make them more reusable.

> sometimes making it work very smoothly and efficiently for all cases,
> like you might imagine, is infeasible or simply a low priority.

I understand that. I thought it would be easy. I do not want to distract
the Racket developers from more important work.

> 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.

I have read something about LLVM and its intermediate representation. Do
you think that using an LLVM-compiled language is more future-proof?

> I know there has been interest in doing more numerical things in
> Racket.

It would be great to be able to do GPU programming.

Cheers,
Marduk

[WarGrey Gyoudmon Ju]

On Sun, Aug 16, 2015 at 6:40 AM, Marduk Bolaños <mard...@gmail.com> wrote:

Coming back to my original question. What is your advice for using
Racket's draw and plot in other programs?

Hi, Marduk.

There was a discussion that is close to your purpose.

http://lists.racket-lang.org/users/archive//2014-January/061247.html

But I think the easiest way is communicating through TCP socket.

You can launch a Racket tcp server application waiting for data sent by your working languages and only do visualizing with it.

[Marduk Bolaños]

Great! Thank you!

Best,
Marduk