Re: Getting Julia beyond the nerd-camp

[Jeffrey Sarnoff]

+1

On Wednesday, October 3, 2012 6:16:23 AM UTC-4, Able wrote:

I liked Go programming (from Google: for its suitability for scientific computing) and have been cgo-wrapping GSL libraries for my personal use. It's a lot of work but was hoping to find help along the way. The problem with Go is that scientific computing is still beneath the useful interest of that camp. Go's main contributors are focusing mostly on server systems and Internet-relevant libraries, which is reasonable.

Since discovering Julia, I can say this is really my camp (being an active scientific researcher in energy engineering) and am interested in seeing this young language succeed. As a genuine compliment, the Julia community is very productive and is bubbling with brilliant design ideas/choices..good work Stefan et al.

While most of the early adopters of Julia are focusing on things that matter in scientific computing (libraries, parallelism/concurrency and optimization/speed), my contribution will be on the softer side of successful language implementation and adoption. To that end I present the following user-side suggestions;

1) The reference/user manual needs to be kept current.

2) More examples of idiomatic Julia could go far in helping early adopters appreciate the sleekness and utility of Julia.

3) Using the web-repl could be made more straight-forward (installation, starting it up, etc)

4) Improved support for Windows (some important scientific commercial software are still Windows-based, meaning that there will always be a lot of interested open-source users stuck on the Windows-world)

Good work!!

[Stefan Karpinski]

Welcome to the mailing list and thank you for the compliments and suggestions. Regarding your points:

• We do try to keep the manual up-to-date although it's a bit of a struggle as things change (pull requests and issue reports on inaccurate documentation are always welcomed), and we certainly could use more examples of idiomatic Julia usage.
• Windows support exists and is actually currently in the process of being merged into master. That will drastically improve the status of Julia on Windows. (Immense thanks to Keno and Jameson for all their work on that.)
• The web repl is going to be phased out and will be replaced with a Julia backend for the iPython Notebook system.

I really like Go and think it's a great design. I don't, however, think though that Go is particularly apt for scientific programming (nor was it designed to be) — at least not any more so than C already is.

The most obvious issue is that Go shies strongly away from polymorphism and operator overloading. For a systems programming language, I think these are both sound decisions. In mathematical programming, however, you really want a *lot* of polymorphism, because mathematical operations like + and * (not to mention indexing operations) are highly polymorphic and you really want to be able to overload them yourself and easily patch in special cases where you have faster ways of computing things. Operator overloading like in C++ almost gives you this, but fails in cases where argument types can't be statically known. Multiple dispatch gives the desired correct behavior in all cases and is a powerful generalization of both single dispatch and operator overloading.

[Julia isn't the first mathy language to recognize this. Mathematica uses a form of multiple dispatch combined with symbolic rewriting. Fortress also chose multiple dispatch for the same reasons. I believe that Sussman et al.'s SCMUTILS implements a multiple dispatch system in Scheme as well.]

Another issue with Go for scientific computing is that it is not a dynamic language and requires a compilation step before code can be run. Interactivity has been crucial to the success of technical environments in the vein of Matlab, R and SciPy. Adding a compile step to people's workflows while doing data analysis, algorithmic exploration, etc., would be a huge step backward these systems.

Thanks again for your input and welcome to the group.

Stefan

p.s. "et al." = Jeff Bezanson and Viral Shah, who were there from the beginning, designing and implementing Julia.

--
 
 
 

[BobC]

Julia may be getting to the point that documentation patches should be mandatory in all pull requests (or an explanation why the docs aren't affected by the change).

This should bring several benefits:

1. Developers will RTFM (a surprisingly rare occurrence in many projects)

2. More knowledgeable eyes on the manual will improve its quality.

3. The manual tracks the tip.  Important, since I suspect most Julia users (including newbies) are using the tip.

I believe the initial popularity of the Go project was largely due to (or made possible by) the obsessive attention given to the documentation.  It was sometimes eerily strange how up-to-date it was kept despite the hectic pace of early language evolution.  When newbie questions were asked, the developers would often provide a quick 1-line response followed by a link to the relevant paragraph in the docs.

-BobC

[Elliot Saba]

Stefan, is there discussion on how "integration with the IPython Notebook system" is going to work itself out?  I know this is something that would be a very nice solution as we don't have to build ourselves up from scratch, but I've looked around the IPython source a bit, and this will likely be no minor task.

Is there an open "discussion" issue on github, or a mailing list email where this is being discussed?

-E

--
 
 
 

[Stefan Karpinski]

On Wed, Oct 3, 2012 at 1:12 PM, Elliot Saba <stati...@gmail.com> wrote:

Stefan, is there discussion on how "integration with the IPython Notebook system" is going to work itself out?  I know this is something that would be a very nice solution as we don't have to build ourselves up from scratch, but I've looked around the IPython source a bit, and this will likely be no minor task.

Is there an open "discussion" issue on github, or a mailing list email where this is being discussed?

The plan is *only* to support iPython Notebook, not any other iPython frontends, since iPython Notebook is written in JavaScript using a well-defined, language agnostic protocol to communicate with a Python backend. The idea is to implement a Julia backend instead and have the JavaScript frontend talk to that. If other iPython frontends end up refactored to use the same protocol, then we would automatically support them, but until that happens, we won't.

I just created an issue to track and discuss this: https://github.com/JuliaLang/julia/issues/1330.

[Able Mashamba]

Thank you Stefan for the comprehensive on-the-mark response. 

Thanks Jeff, Viral and Stefan (again) for the vision of need and the knack to get this project started and going..you guys should be entrepreneurs. Thumbs up to the tirelessly prolific contributors like Tim, Tom, Doug, Mike, Elliot, Dave, Mark .. and the rest of the growing super team.  Julia is really one of those few languages designed with scientific computing at heart among a select few that include Fortran, X10, Chapel, Fortress, R, Matlab, Octave and Mathematica. Languages like Python and C/C++ (and Javascript?) are being used for scientific computing by necessity rather than by design. 

For a language this young, the current list of Julia features, capabilities and libraries is non-trivial. It's going to be easy to do technical (hp) computing, web-scripting and database application dev in one easy and fast language for anyone who cares. And to think that I did my PhD using some bitter concoction of C/C++, Fortran 95 (with expensive ISML from Intel), Matlab and CPython glue ...blood, sweat and tears for a non-computer science major (engineer) like me.

Will try to interest colleagues into experimenting with and adopting Julia.

Keep up the good work, guys. All said, I salute you!

Able

--
 
 
 

--
Able