I think types+dispatch is the right way to go. It's what Julia is founded 
upon, and it's what leads to really fast computations. A fast type/dispatch 
based symbolic system for Julia and in pure Julia would be a huge asset. 
And while the post said not to mention the front end, when talking about 
Mathematica you have to talk about the front end. The only reason why I use 
it over other CAS' is because that notebook looks like math. Until someone 
implements something like that in Julia, I will always have a reason to 
open up Mathematica.

On Thursday, September 1, 2016 at 3:22:12 PM UTC-7, [email protected] 
wrote:
>
>
>
> On Thursday, January 23, 2014 at 11:47:11 PM UTC+1, Акатер Дима wrote:
>>
>> It's mentioned here 
>> http://julialang.org/blog/2012/02/why-we-created-julia/ that Mathematica 
>> was one of the programs that inspired Julia. How does Julia compare to 
>> Mathematica's language?
>>
>> To make the question more specific,
>>
>> - it's about languages, not implementations, so Mathematica's FrontEnd 
>> capabilities are irrelevant (and it's also not about “which one is faster”)
>> - it's not about free vs non-free
>> - it's not about communities and support
>> - it's not about anything related to OOP (feel free to write about, sure, 
>> but I will probably be very passive in discussions concerning OOP)
>>
>> - it's about the languages' most high-level features, like 
>> meta-programming, macros, interactions with other languages and the way it 
>> treats types
>>
>> For example, Wolfram language (which is now the name of Mma's core 
>> language), implements meta-programming capabilities via term-rewriting and 
>> Hold. It provides some foreign-language interfaces via MathLink (which 
>> could be WolframLink already) and also has SymbolicC. It is untyped and 
>> proud of it; types can be implemented easily but they are of little 
>> practical need in the absence of compiler.
>>  
>>
> - it's also about the languages' most distinctive features: are there 
>> things Julia has that WL does not have? (Which means adding them to WL 
>> would require reimplementing Julia in WL, much in spirit of Greenspun's 
>> tenth rule.)
>>
>>     I think it is easier to go the other direction and implement 
> something like Mma in Julia. This is what I have done here:
>
>     https://github.com/jlapeyre/SJulia.jl
>
> I think Julia is uniquely well suited for implementing a Mma-like 
> language.  I agree with the comment below that Mma is designed in part to 
> appeal to non-programmers. A large part of its appeal is that it collects a 
> lot of mathematics functionality that is hard to find elsewhere... all 
> kinds of algorithms and special functions. Many of these can be used with 
> one or a few lines of code. I kept the non-programmer in mind when writing 
> SJulia.
>
>    The question of what kind of type system a language has is somewhat 
> polemic. In some sense, Mma is untyped. There is no hierarchy in 
> expressions; they all have a head and arguments. I think hierarchies of 
> mathematical objects are not well represented by hierarchies of programming 
> language types. Which hierarchy a particular mathematical object belongs to 
> and its exact definition is very fluid. Languages like Mma that attach no 
> inherent meaning to expressions are well suited for mathematics for 
> scientists and engineers. A matrix is an expression with head 'List' each 
> of whose elements is an expression of fixed length with head 'List'.  Still 
> types creep into Mma in various ways. 
>
> Some people prefer types to play a larger role in symbolic computation. 
> For instance:
>
> http://www.sympy.org/en/index.html
>
> https://github.com/jverzani/SymPy.jl
>
> http://nemocas.org/
>
> Whether to use types depends in part on the domain of the language.  But 
> even for rather general math capabilities, language design determines in 
> part the role of types. Sympy (in python and Julia) aim to add symbolic 
> computation capability to Julia.  They are more 'typed' than Mma and 
> SJulia. But, it seems that python sympy is hybrid in this respect and also 
> supports generic expressions.
>  
>
>> To provide a starting point, here is the definition of type in Julia from 
>> documentation http://docs.julialang.org/en/latest/manual/metaprogramming/
>>
>> type Expr
>>   head::Symbol
>>   args::Array{Any,1}
>>   typend
>>
>>
>> Maybe there's a typo in docs (line 4) but it doesn't really matter. What 
>> do Julia users do, for example, to avoid boilerplate code defining lots of 
>> types? I understand how to avoid writing boilerplate definitions in WL: it 
>> may not be easy but at least I know where to begin in case I need a program 
>> that would write new definitions or update existing ones.
>>
>

Reply via email to