I should probably add, since it might excite you Harald, that most syntax
in Julia does not actually exist in the language proper. Much of the syntax
is defined in library code, e.g. array access, the dot notation and all
sorts of other things.
But because of the way Julia operates, all of that does not come with a
runtime penalty. You can see from Stefan's examples above that many
abstractions in Julia come with zero "runtime" cost. So an array access, or
a range syntax, or a dot notation (well, in the next version anyway), etc,
can all be overloaded with user defined functions for any type, or
typeclass, or union of types or parameterised class of types, or whatever.
But those function calls don't result in a runtime penalty when used.
Thus the language is formally extensible at no cost and in an extremely
simple way that the user can easily do themselves. Again, total domination
of Python.
This is similar to the way Lisp was the first language to have OO, since
the language was formally extensible by the user, and so people just wrote
macros which did the OO stuff. The only difference is, that was hard to do
unless you understood a lot about metaprogramming in Lisp. In Julia, anyone
can do it.
julia> getindex(a::Array{Int, 1}, b::Int) = print("test")
getindex (generic function with 140 methods)
julia> a = [1, 2]
2-element Array{Int,1}:
1
2
julia> a[2]
test
Bill.
On Thursday, 21 August 2014 17:36:20 UTC+2, Bill Hart wrote:
>
> Sorry, my answer to your question about tab completion was incomplete. I
> posted it before rereading it.
>
> You can define the A.b syntax in Julia if you should so desire. It's
> essentially just another kind of method overload in Julia.
>
> And then, it supports A.<tab> giving a list of all the things that could
> follow the dot, just as Python would.
>
> For example Pkg.<tab> yields:
>
> Pkg.Cache Pkg.Resolve Pkg.edit Pkg.register
> Pkg.DEFAULT_META Pkg.Types Pkg.eval Pkg.release
> Pkg.Dir Pkg.Write Pkg.fix Pkg.resolve
> Pkg.Entry Pkg.add Pkg.fixup Pkg.rm
> Pkg.Generate Pkg.available Pkg.free Pkg.status
> Pkg.META_BRANCH Pkg.build Pkg.generate Pkg.tag
> Pkg.Pkg Pkg.cd Pkg.installed Pkg.update
> Pkg.Query Pkg.checkout Pkg.init
> Pkg.Read Pkg.clone Pkg.pin
> Pkg.Reqs Pkg.dir Pkg.publish
>
> But you have to ask yourself how useful that actually is. If you want to
> write Python in Julia, I suppose it is useful. But the Julia paradigm is
> different to the Python paradigm. You might actually find that Julia is not
> generically used that way very much.
>
> On Thursday, 21 August 2014 17:26:50 UTC+2, Bill Hart wrote:
>>
>>
>>
>> On Thursday, 21 August 2014 10:58:36 UTC+2, Harald Schilly wrote:
>>>
>>>
>>>
>>> On Wednesday, August 20, 2014 4:54:35 AM UTC+2, Bill Hart wrote:
>>>>
>>>> Oh what a shame I missed the party. And I don't have time to read all
>>>> the wonderfully eloquent nonsense in this thread.
>>>>
>>>
>>> So, since we both are the only remaining hangover crowd, I've one last
>>> question about Julia:
>>>
>>>
>>>>
>>>> But I think Julia is good for a few years yet. It's one of the few
>>>> truly 21st century programming languages available.
>>>>
>>>
>>> All your arguments center around technical arguments: speed, efficiently
>>> maintenance of "exponentially" growing complexities in codebases, etc.
>>> Those are without question desirable properties. What's missing for me is
>>> the other side for the actual humble user of this.
>>>
>>> Python's roots are in ABC (which does not stand for abstract base
>>> classes, but for the effort to produce a human friendly programming
>>> language as a basic successor). Does Julia have such goals?
>>>
>>
>> I think it manifestly does. Julia was inspired by Lisp, Python and a
>> third language that I forgot. The syntax is very pythonic, where the
>> language doesn't fundamentally deviate from the paradigm python belongs to.
>> I would say I'm far more productive in Julia than I could be in Python. It
>> makes easy things easy, intermediate things intermediate and difficult
>> things feasible. Python does not do this. Many difficult things are nearly
>> impossible in Python and many intermediate things are very hard.
>>
>> Second question is about multi-dispatch, and goes in the same direction:
>>> Given I have an object behind x, is there a x.[TAB] which lists me what I
>>> can "do" with it?
>>>
>>
>> Yes. Note the dot notation is not used in Julia. It uses a different
>> paradigm (multi-methods, not classes). The Julia approach is much easier
>> and far less restrictive than the usual OO paradigm.
>>
>> Given a type A I can do methodswith(A) and it will list all methods that
>> use type A *anywhere* in their prototype.
>>
>> But the focus in Julia is usually on functions, not objects. So it is
>> more usual in practice to be writing methods(A) where A is the name of a
>> *constructor* for a type (usually also called A). The constructor for A is
>> a generic function with numerous methods, and methods(A) will give you a
>> short list of methods that can be used to construct A (which usually won't
>> have A at all in their prototype -- unless you count the return value --
>> yes, it would appear explicitly in the prototype in Python and implicitly
>> in the prototype in C++, but not in Julia which doesn't overload on return
>> type).
>>
>>
>>> Or does this playful way of discovering functionalities work
>>> differently?
>>>
>>
>> It does. But it is extremely practical.
>>
>> There's also an online help system baked right into Julia. So you can get
>> help on any function, method, type, etc. And this is generated
>> automatically, though you can add your own documentation to that system
>> easily.
>>
>> It's also trivial to extend Julia's assistance to the user in whatever
>> way you like. One of my favourite things is the ability to be able to
>> overload the show method for any given type and any given value of any
>> type. Doing the former will change the way the type is displayed. E.g.
>>
>> julia> R, x = PolynomialRing(ZZ, "x")
>> (Univariate polynomial ring in x over ZZ,x)
>>
>> Note that the type R is really Poly{ZZ, :x} in Julia's notation. But we
>> overload the show method to display ("Univariate polynomial ring in ",
>> string(:x), " over ", ZZ).
>>
>> And the polynomial x would usually be displayed as Poly(2, 2,
>> 0xa56c4856727f0a40). We overload the show method to display "x".
>>
>> I personally think Julia dominates most other languages entirely. I would
>> certainly include Python in that. I can't think of a single feature of
>> Python I would miss in Julia, including easy to use syntax.
>>
>> Some languages I think that aren't completely dominated by Julia are
>> Rust, D and Nimrod, and to some degree C++, though it certainly completely
>> dominates more areas of C++ than those other languages.
>>
>> When I say "some languages" I'm only referring to languages with
>> imperative syntax. There are functional languages that aren't strictly
>> comparable.
>>
>> Note, Julia is not some obscure unheard of language. It gets 150,000
>> visits a month to its website. And it is gaining popularity rapidly. There
>> are already hundreds of user contributed packages for Julia (which by the
>> way you can download into any Julia session connected to the internet by
>> typing Pkg.add("name of package").
>>
>> I doubt it would be this popular if it had awkward syntax.
>>
>> Take a look at my Nemo documentation and see if you feel comfortable with
>> the syntax:
>>
>> http://www.flintlib.org/nemo.pdf
>>
>> Note that Nemo is Julia, in the same way as Sage is Python. There is no
>> preparser used in Nemo.
>>
>> Julia is not the best possible language for computer algebra. I list some
>> of the issues I have with it in my nemo.pdf above. But the Julia developers
>> are actively thinking about some of those. It's even possible that Julia
>> will always suffice and I'll not need to finish writing my own language.
>> There are a couple of things which I consider to be fundamental design
>> decisions in Julia which I think make it impossible to get the best
>> possible performance. But the Julia language designers have rebuffed me on
>> that point, stating that they don't consider them to be fundamental design
>> decisions at all. They are indeed looking at ways of at least mitigating,
>> if not removing those performance deficits in later versions of the
>> language. We'll see. I know how hard it is, because I've done some of those
>> things in my own toy language. Writing languages is very hard and can take
>> decades to get right.
>>
>> Bill.
>>
>>
>>> -- H
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
