Live data from Hacker News

Julia: A fresh approach to numerical computing

arxiv.org

91–100 of 146 posts

Re: Julia: A fresh approach to numerical computing

#91
post #41

Earlier quoted context omitted.

I think the point is that it special-cases the first object, at least in the syntax. You _could_ write it that way, but since the method is chosen based on all the object types, it doesn't make much sense to do so.

The point was that object.method() is sometimes more readable . For example I find web_socket_manager.reconnect_if_needed() more readable than reconnect_if_needed(web_socket_manager).

That's because you are used to thinking in terms of objects, whereas in Julia the focus is on data and operations on data (the two are often conflated but they aren't the same).

Re: Julia: A fresh approach to numerical computing

#92
post #4

What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn'…

One of the few things I don't like is that it lacks a bit for object-oriented programming. Specifically: - It doesn't use the object.method() syntax, which is often more natural and readable than method(object). - Support for interfaces but I'm not 100% sure about that.

It is only more natural for functions that take a single argument, which depending on your point of view and type system is of course all of them.

From a mathematical standpoint what you are doing is to consider instead of objects X themselves, arrows from some fixed object I, x : I -> X (roughly speaking the "I points of X", in the category set I could for example be the one element set), then given another arrow f : X -> Y, the composition I -> X -> Y, would be denoted x . f, and you would actually find that in familiar cases this is precisely f(x).

However for this to actually be natural, ideally you wouldn't write x . add(y), but (x,y).add and if you follow that line of thought you would probably understand why stack based languages enjoy some popularity (the stack models the cartesian product).

Object oriented languages instead have for every I point x of X, a bifunctor hom_x(,), where hom_x(Y,Z) denotes all arrows from Y to Z, that "use" the point x (usually denoted by self or this). At least in mathematics, such an arrow can sometimes be extended to an arrow in Hom_X(Y,Z). In the case of addition above, you start off with + : (X , X ) -> X and use currying to get add : X -> hom(X,X) and pullback along x, to get $x^{\ast}add = add_x \in hom_x(X,X)$, which you then denote by x.add.

So you are right, the object method syntax is more natural and there even was a brief period in the 60s-70s when some mathematicians argued that it should be taught.

Re: Julia: A fresh approach to numerical computing

#93

Are there any mature visualization libraries for Julia yet? I'm pretty excited about this language, but I couldn't find any visualization tools that had good documentation.

Gadfly is an excellent ggplot2-style plotting package:

http://gadflyjl.org

Winston is a most traditional plotting API:

http://winston.readthedocs.org/en/latest/examples.html

You can also plot seamlessly via Python using PyPlot:

https://github.com/stevengj/PyPlot.jl

They are all quite well documented.

Re: Julia: A fresh approach to numerical computing

#94

Earlier quoted context omitted.

The first two are both WIP. Threading is https://github.com/JuliaLang/julia/tree/threads (although it hasn't been updated in a little while) and static compilation of modules is https://github.com/JuliaLang/julia/pull/8745

That's great to see. It's sometimes hard to keep up with everything that's going on. Incidentally I really got a kick out of the recent s/Uint/UInt/ rename ( https://github.com/JuliaLang/julia/issues/8905 ). It took a day or so to propose and do it. To compare, java will probably never fix it's spelling oddities (for example int and Integer). Very refreshing to see fundamental things like that be fixed and so quickly…

Just to play devil's advocate about the Java capitalization, I suspect the difference between `int` and `Integer` is quite intentional: `int` is a "primitive", immutable value type, while `Integer` is a class. Since by convention, Java's classes are capitalized, while its primitives are spelled the way they are in C, there's some sense here.

Re: Julia: A fresh approach to numerical computing

#95
post #18

Earlier quoted context omitted.

One of the few things I don't like is that it lacks a bit for object-oriented programming. Specifically: - It doesn't use the object.method() syntax, which is often more natural and readable than method(object). - Support for interfaces but I'm not 100% sure about that.

Object.method() doesn't really make sense due to multiple dispatch, I think.

Hm, well it sort of does make sense if you have tuples, it would be just

(object_1,...,object_n).method

Re: Julia: A fresh approach to numerical computing

#96

Earlier quoted context omitted.

There is work happening on the UI side in Julia. While we are some ways away from building graphical clients in Julia, we do have GTK bindings and such. For some interesting ideas borrowed from Elm, do see: https://github.com/shashi/Patchwork.jl

Is anyone working on direct Qt bindings (I don't consider using PyCall a viable option). Qt is a bit harder to wrap since it is C++, but it look like Lua has been able to auto generate bindings based on the Qt headers.

Keno Fischer, who recently created the Cxx package [1] used to be a Qt dev, so I wouldn't be terribly surprised if we see such bindings materialize in the future, using Cxx, of course. That said, I don't want to speak for him, so if someone wants this, they should maybe go ahead and start working on it!

[1] https://github.com/Keno/Cxx.jl

Re: Julia: A fresh approach to numerical computing

#98
post #81
post #47

Earlier quoted context omitted.

This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can…

Dictionary performance is still slow from what I can't tell. Like 2x slower than Python last time I checked. https://groups.google.com/forum/#!topic/julia-users/hxfR70Ro... I also find the dataframe library to be much harder to use/not much faster than pandas. Great community though.

The dataframe dev is really responsive though. We worked through a bug together a few weeks back. Nice experience overall.

Re: Julia: A fresh approach to numerical computing

#99

Are there any mature visualization libraries for Julia yet? I'm pretty excited about this language, but I couldn't find any visualization tools that had good documentation.

Gadfly is an excellent ggplot2-style plotting package: http://gadflyjl.org Winston is a most traditional plotting API: http://winston.readthedocs.org/en/latest/examples.html You can also plot seamlessly via Python using PyPlot: https://github.com/stevengj/PyPlot.jl They are all quite well documented.

Still working my way through them myself. Useful examples working through docs would be useful. Most seem to presume a lot of knowledge of the libraries.
Post reply on HN