On 4/28/2012 6:27 AM, Manuel Pedrinero rossetil wrote:
> The people of julia language are trying to make a language that can
> replace R and Matlab. Lisp is used to manipulate the AST, there is
> a small Lisp developed by one of the core members of the group
> (femlisp) available in github.
>
> I think that julia could be a good replacement for the maxima
> language. Julia can use LAPLACK and other libraries, and recently
> in the list there has been some talks about CPYTHON developers trying
> to link with julia.
Pro: Since Maxima is implemented in Lisp, it would seem that femlisp
would be unnecessary to implement
Julia in the same core image as Maxima. So an additional
read-eval-print loop that looks like Julia
but has the Maxima system as its "library" should be simple, and someone
familiar with Lisp could
rapidly implement at least a demonstration of Julia interfaced to Maxima.
Con: Many people with experience using Maxima or Macsyma have suggested
improvements or changes to the language.
Are you aware of these issues? If you are not aware of them, your new
language design
might not address them at all.
A glance through the Julia tutorial suggests that it is not especially
supportive of computer algebra,
since it lacks an arbitrary precision integer type.
Access to libraries for numerics, graphics, web access,
parallel constructs, etc are generally well known to Lisp implementors;
unfortunately the level of
support and the details differ between implementations. It is not clear
to me that Julia's features
in this regard would be a big selling point in any case, unless you
re-implemented all of Maxima
in Julia, not just the front end Maxima language.
Perhaps you could share with us your reasoning as to why the maxima
language needs to be replaced.
If you have limited experience with symbolic computing, it really
doesn't work to just claim that
"Julia is good for whatever you are doing, whatever you are doing",
since it probably reflects
a sentiment not a reason: for example,
"I like Julia, and I really don't know what you are doing, but maybe
you'll like it too."
>
> For julia developers adding symbolics capabilities could be very
> interesting.
Probably the case. The legacy of Lisp in Julia's metaprogramming seems
to have
good intentions, but it is hard to get enthusiastic about the plethora
of notations
inherited from c, c++, java, ... unless one is first familiar with them
and not lisp
z.head instead of (first z) or (car z)
z.args instead of (rest z) or (cdr z)
The target audience for Macsyma/ Maxima language is usually considered
(a) people who do not know other programming languages (like C or Lisp)
but are familiar
with mathematical notation and would like to continue using it as much
as possible.
and
(b) people who (probably knowledgeable about PLs) would like to present
programs that are relatively concise and easy to explain to persons familiar
principally with mathematical notation. That is, there should be a
minimum of
programmer-ese. (like foo++, a//b, glub.args ...).
> For maxima developers, being able to interface with R, C and fortran
> could be also very interesting,
> so I think this is a win-win situation.
Probably not, as I said above, unless the back-end is written in Julia,
this won't happen
via Julia. It could continue to happen (in all dialects of Common Lisp
supporting
Maxima except, apparently GCL), simply by using Lisp foreign-function
interfaces.
The success of a new programming language does not seem to depend so much
on its intrinsic merits as on other factors. How else to explain the
rise of
so many languages, including many derided by academics as really bad
designs.
Some of them fall into disuse, but certainly not all.
RJF