I didn't completely understand this discussion.
I looked briefly at "femlisp", and it appears to be a language implemented _in_ (Common) Lisp, rather than another implementation _of_ Lisp.
I've never understood the penchant for hacking syntax; it appears that 95% of the differences between computer languages have to do with syntax, and 95% of those differences are trivial, yet provide huge barriers (perhaps intended) to people learning and expressing themselves in these languages.
I'm glad to see that people are hacking FEM in Lisp & these people should be encouraged as much as possible.
I don't know who said it first, but Lisp has proven to be much better than the vast majority of its successors (wannabes?).
I'd love to see another Lisp, but one based on interesting semantic improvements rather than any syntax changes. The most important elements on my list of improvements have to do with concurrency, parallelism, clean separation of pure (referentially transparent/side-effect-free) and impure (assignments) constructs, incorporation of persistence, incorporation of editing/program development/debugging model.
Interestingly, this list hasn't really changed in 20 years, but modern computer languages still haven't successfully addressed these issues.
At 08:05 AM 4/28/2012, Richard Fateman wrote:
>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