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.
