Julia Impressions(eyeballtrees.com)
eyeballtrees.com
Julia Impressions
http://eyeballtrees.com/posts/julia-impressions.html
14 comments
I used Julia's in-built profiler to look at your code. Almost all the work is done, as you'd hope, on lines 20, 22, 33, and 35. I added @inbounds to lines 20 and 35, figuring that line 22 is mostly just the effort of calculating tanh. This dropped the running time on my computer from 10.7 seconds to 6.4 seconds, so about 60% of original running time. If I compile with gcc (gcc rnn_perf.c -O2 -o rnn_perf -lm) and run that, I get 6.2 (O3 is worse). That might not be how you compiled the C version, but regardless it looks like your C time was about 46% of the original Julia time, so its getting close. Three-fifths of the work now is in the tanh line. I'll submit a PR.
Thanks a ton Iain, it pushed it down by 60% on my end as well. About the C code, I used -O2, the specific compiler flags are in the rnn_perf.sh file.
https://github.com/ninjin/ppod/commit/ce7665a2cfd045332e9861...
Julia is really tempting for my next project, the benefits of scripting without all the OOP cruft and a community that just shines. Also, did I mention the awesome meta programming?
https://github.com/ninjin/ppod/commit/ce7665a2cfd045332e9861...
Julia is really tempting for my next project, the benefits of scripting without all the OOP cruft and a community that just shines. Also, did I mention the awesome meta programming?
Having people like Iain – with this kind of knowledge of numerical programming and optimization – help you out with your code is one of the major benefits of Julia programming :-)
This is some quality advertising on your and Iain's part. It makes me want to use Julia even more when I get the chance.
Wow. If this is what the community in Julia is like, count me in.
I've been focusing on mastering the scientific libraries of Python and waiting until I hit performance walls before I took Julia on, but perhaps I'll start now.
I've been focusing on mastering the scientific libraries of Python and waiting until I hit performance walls before I took Julia on, but perhaps I'll start now.
I also starting working on a neural network implementation for my first foray into Julia:
https://github.com/bachase/nnadl-julia.
The notes file on the optimization branch is a very rough outline of things I discovered while iterating on performance. Outside of Iain's great advice and without profiling your code, for a larger sized network, you might benefit from reordering loops for column major storage, or doing normal matrix multiplication (which uses BLAS) followed by a devectorized tanh.
As for the language, I love being able to get something working quickly while writing in a Matlab/"mathy" style. The built in profiler and timer tools are then excellent for zeroing in on hotspots and memory allocations. I'm just amazed at how simply I can drill down from scripting style code to LLVM IR to native asm all in an ijulia notebook browser window.
On the downside, I'm not a fan of having to manually devectorize to avoid temporaries, especially given the success of c++ libraries like Blitz that figure it out for you. I'm sure Julia will improve in this area as it matures.
https://github.com/bachase/nnadl-julia.
The notes file on the optimization branch is a very rough outline of things I discovered while iterating on performance. Outside of Iain's great advice and without profiling your code, for a larger sized network, you might benefit from reordering loops for column major storage, or doing normal matrix multiplication (which uses BLAS) followed by a devectorized tanh.
As for the language, I love being able to get something working quickly while writing in a Matlab/"mathy" style. The built in profiler and timer tools are then excellent for zeroing in on hotspots and memory allocations. I'm just amazed at how simply I can drill down from scripting style code to LLVM IR to native asm all in an ijulia notebook browser window.
On the downside, I'm not a fan of having to manually devectorize to avoid temporaries, especially given the success of c++ libraries like Blitz that figure it out for you. I'm sure Julia will improve in this area as it matures.
I was curious to know how modern C++ would compare. Here is a version (not 100% sure about the result because I was not 100% sure of the meaning of some of the numpy constructs when applied to matrixes).
http://chronos.isir.upmc.fr/~mouret/tmp/nn_eigen3.cc
It seems pretty fast!
http://chronos.isir.upmc.fr/~mouret/tmp/nn_eigen3.cc
It seems pretty fast!
> my own Cython code has started to fail me performance-wise.
I think this is an odd statement, seeing as how Cython allows you to write pure C code without making any use of the Python C API, so by definition Cython can be as efficient as C minus a single function call from Python to C.
I think your benchmark is way too small to be interesting. You're only testing raw numerical performance, and of course C wins there. Any of these languages allow you to wrap a C library with more or less convenience. I think the more interesting questions are how well these languages allow you to build larger applications with performance-sensitive components, how extensive the ecosystem of libraries is, and the quality of debugging and profiling facilities.
I think this is an odd statement, seeing as how Cython allows you to write pure C code without making any use of the Python C API, so by definition Cython can be as efficient as C minus a single function call from Python to C.
I think your benchmark is way too small to be interesting. You're only testing raw numerical performance, and of course C wins there. Any of these languages allow you to wrap a C library with more or less convenience. I think the more interesting questions are how well these languages allow you to build larger applications with performance-sensitive components, how extensive the ecosystem of libraries is, and the quality of debugging and profiling facilities.
Just curious, is it possible to vectorize your MATLAB implementation? In your test code you don't use the loop index in the calcs, so that makes it hard for me to tell if it is or is not possible to vectorize it for your actual application.
What are the libraries like for Julia at this point? The big thing holding me to R is the breadth of libraries for a) various statistical methods and algorithms and b) plotting.
I'm kind of desperate to get away from R at this point, but reluctant to move to Python (not that I have anything against Python, but I would really like to add a high performance language to my toolkit than something inbetween).
I'm kind of desperate to get away from R at this point, but reluctant to move to Python (not that I have anything against Python, but I would really like to add a high performance language to my toolkit than something inbetween).
It depends on what you need. DataFrames [1] is a pretty good replacement for R's data frames. Distributions [2] is pretty amazing. Gadfly.jl [3] is a great ggplot-style plotting library that integrates nicely with IJulia [4]. If you have questions about specific things you need to do and want pointers, post on the julia-users list [5] and you should get some good answers.
[1] http://harlanh.github.io/DataFrames.jl/
[2] http://distributionsjl.readthedocs.org/en/latest/
[3] https://github.com/dcjones/Gadfly.jl
[4] https://github.com/JuliaLang/IJulia.jl
[5] https://groups.google.com/forum/#!forum/julia-users
[1] http://harlanh.github.io/DataFrames.jl/
[2] http://distributionsjl.readthedocs.org/en/latest/
[3] https://github.com/dcjones/Gadfly.jl
[4] https://github.com/JuliaLang/IJulia.jl
[5] https://groups.google.com/forum/#!forum/julia-users
Thanks!
Out of curiosity, why are you so desperate to get away from R? Is it for the speed of a high performance language?
As you mention, the vast selection of libraries (and the continual development of these libraries) make even the python module universe look small (in reference to statistical methods, statistical algorithms/machine learning, plotting).
Further, not only are there a lot of libraries.. but many of them are bleeding edge written by the same people who originally invented the given algorithm. Most similar libraries in other languages (like Python) have incomplete ports of these libraries to them often not written by the same people. Not to mention, the documentation behind these algorithms is often excellent - besides the usual man files, there's "vignettes" (detailed instruction manual) as well as an entire journal that now has become a place to publish papers detailing the usage and implementation of many of these algorithms.
So I'm curious, why leave?
As you mention, the vast selection of libraries (and the continual development of these libraries) make even the python module universe look small (in reference to statistical methods, statistical algorithms/machine learning, plotting).
Further, not only are there a lot of libraries.. but many of them are bleeding edge written by the same people who originally invented the given algorithm. Most similar libraries in other languages (like Python) have incomplete ports of these libraries to them often not written by the same people. Not to mention, the documentation behind these algorithms is often excellent - besides the usual man files, there's "vignettes" (detailed instruction manual) as well as an entire journal that now has become a place to publish papers detailing the usage and implementation of many of these algorithms.
So I'm curious, why leave?
I love a lot about R, and I totally acknowledge the benefits. I don't think I would ever stop using it for data exploration and ad hoc analysis.
But after trying really hard over the past 3 years I'm sort of giving up ever being able to use it in a productive reliable fashion for building more complex software. It's a failing on my own part in many ways, but the loose typing and poor support for structuring code interact very badly with my personal style. When I'm working in R I literally spend 80% of my time fighting with the type system, debugging weird and wonderful features of R. I'm at the point where whenever I write an R function the first 50 lines of the code are type checks to make sure the data coming in is what I expect. I came to this point after I started systematically tracking why I was wasting so much time, and nearly every time it would come back to the type of my data being something other than what I had expected or assumed.
So I'm sort of figuring if I'm at the point where I'm writing manually statically typed code in R ... I should look around for a language that's just like R but has at least slightly stronger data types built in.
But after trying really hard over the past 3 years I'm sort of giving up ever being able to use it in a productive reliable fashion for building more complex software. It's a failing on my own part in many ways, but the loose typing and poor support for structuring code interact very badly with my personal style. When I'm working in R I literally spend 80% of my time fighting with the type system, debugging weird and wonderful features of R. I'm at the point where whenever I write an R function the first 50 lines of the code are type checks to make sure the data coming in is what I expect. I came to this point after I started systematically tracking why I was wasting so much time, and nearly every time it would come back to the type of my data being something other than what I had expected or assumed.
So I'm sort of figuring if I'm at the point where I'm writing manually statically typed code in R ... I should look around for a language that's just like R but has at least slightly stronger data types built in.
I agree completely on the type system. When first starting with it, I was thinking "wow this is great, I don't have to worry about types and things just work". But then weird things start to happen, and you realize it's due to strange type issues that are sometimes harder than they should be to track down. And then half your code ends up being something like as.numeric(as.character(as.vector(xyz)))
I cannot speak for zmmmmm but I can think of two reasons (i) performance, not that R cant be fast but you have to pull out heavy machinery such as parallelization much earlier and (ii) its inconsistent and confusing language semantics, and silent and unexpected type promotion/demotions that make it very error prone to develop and debug code in. To me the one redeeming quality about R is ggplot and, ok, availability of push button libraries
I am not so sure about the scope of the 'bleeding edge' part. It is popular among old school, statisticians. Another population (no pun intended) that R is popular in is one where one knows neither statistics nor machine learning but just wants to try out a laundry list of canned methods without a need to understand: pretty plot goes up, yay awesome; pretty plot goes down, ok try the next algorithm (or the other way round). Here I think R is pretty unbeatable in its breadth.
It is not that popular among machine learners. Part of it is cultural, a typical machine learning person will be coming from a CS background and then R grates more.
It has been claimed that R is lisp meets stats, I think that would be Julia now and Lush then. http://lush.sourceforge.net/. To quote Yann LeCun:
"Lush combines three languages in one: a very simple to use, loosely-typed interpreted language, a strongly-typed compiled language with the same syntax, and the C language, which can be freely mixed with the other languages within a single source file, and even within a single function."
I am not so sure about the scope of the 'bleeding edge' part. It is popular among old school, statisticians. Another population (no pun intended) that R is popular in is one where one knows neither statistics nor machine learning but just wants to try out a laundry list of canned methods without a need to understand: pretty plot goes up, yay awesome; pretty plot goes down, ok try the next algorithm (or the other way round). Here I think R is pretty unbeatable in its breadth.
It is not that popular among machine learners. Part of it is cultural, a typical machine learning person will be coming from a CS background and then R grates more.
It has been claimed that R is lisp meets stats, I think that would be Julia now and Lush then. http://lush.sourceforge.net/. To quote Yann LeCun:
"Lush combines three languages in one: a very simple to use, loosely-typed interpreted language, a strongly-typed compiled language with the same syntax, and the C language, which can be freely mixed with the other languages within a single source file, and even within a single function."
You definitely have some good points - I agree on points (i) and (ii) - these are shortfalls of the language and in many cases (especially when building production level code) may be reasons to switch).
I disagree with you premise that R is not popular among machine learners and the implication that has for the "bleeding edge" comment. Perhaps it is less popular with ML people coming from a CS background - but it seems to be the most widespread language for ML (or "statistical learning") among statistics people. And that fact is not to be discounted - perhaps the preeminent book on machine learning (or at the very least one of the most popular) - "The Elements of Statistical Learning" - is written by statisticians (and in fact uses R exclusively!). The Journal of Statistical software, which features papers detailing many ML libraries, has far larger coverage of R packages than any other language: http://www.jstatsoft.org/ . I would suggest this is the evidence for the "bleeding edge" comment. Other languages' packages, say Python's ML libraries (scikit-learn, pyBrain, etc.), do note even come close to the breadth of capability in this space.
Coming from a statistics background,- I would venture to ask.. what's wrong with "pushbutton" libraries? And why are they only useful to people who do not know/understand much about ML/statistics?
Say you have a dataset and you believe ,say, a Random Forest would be well suited to predicting some response. Let's assume you have a very good understanding of Random Forests. Why would you not want a push-button library? Why would you WANT to recode the thing yourself? It's not as if your Random Forest will be any better or "more correct" than the one on CRAN or whatever language's repository you are using. I would argue it's more likely to have mistakes (coding something like this from scratch is no small task and the ones on CRAN have often gone through many iterations, improvements, and reviews from many experts in the field). And let's say you have some domain knowledge or some informed belief about how the Random Forest needs to be adapted to your particular problem (a different loss function or something) - you can easily edit the R package source code to do that - no need to rebuild the car just to give it a new paint job...
I disagree with you premise that R is not popular among machine learners and the implication that has for the "bleeding edge" comment. Perhaps it is less popular with ML people coming from a CS background - but it seems to be the most widespread language for ML (or "statistical learning") among statistics people. And that fact is not to be discounted - perhaps the preeminent book on machine learning (or at the very least one of the most popular) - "The Elements of Statistical Learning" - is written by statisticians (and in fact uses R exclusively!). The Journal of Statistical software, which features papers detailing many ML libraries, has far larger coverage of R packages than any other language: http://www.jstatsoft.org/ . I would suggest this is the evidence for the "bleeding edge" comment. Other languages' packages, say Python's ML libraries (scikit-learn, pyBrain, etc.), do note even come close to the breadth of capability in this space.
Coming from a statistics background,- I would venture to ask.. what's wrong with "pushbutton" libraries? And why are they only useful to people who do not know/understand much about ML/statistics?
Say you have a dataset and you believe ,say, a Random Forest would be well suited to predicting some response. Let's assume you have a very good understanding of Random Forests. Why would you not want a push-button library? Why would you WANT to recode the thing yourself? It's not as if your Random Forest will be any better or "more correct" than the one on CRAN or whatever language's repository you are using. I would argue it's more likely to have mistakes (coding something like this from scratch is no small task and the ones on CRAN have often gone through many iterations, improvements, and reviews from many experts in the field). And let's say you have some domain knowledge or some informed belief about how the Random Forest needs to be adapted to your particular problem (a different loss function or something) - you can easily edit the R package source code to do that - no need to rebuild the car just to give it a new paint job...
I guess everyone has left the building, leaving a reply in case you see it.
>I disagree with you premise that R is not popular among machine learners
I know what you are saying, and I agree, that is why I chose my words carefully.
There is a quite a lot of variation here. In one subset, if you know the ins and outs of R you will be taken for a wizard, in another subset just listing R/MATLAB as one of your major skill will actually work against you.
> what's wrong with "pushbutton" libraries?
Nothing at all and I did not claim its wrong either. In fact I said that is one of R's strengths. For people who arent into the theory of statistics or ML then R can be a heaven sent. Especially if all they want to do is try out a catalog of algorithms.
The analogy I use is that of an automobile industry. If your goal is to be a run off the mill automobile driver/chauffeur R is your competitive advantage. If your goal is to be an automotive engineer (design new models and algorithms) R is an inferior tool. In fact if you want to be a F1 racer, you have to look elsewhere too. Like every tool it has its sweet spot, as long you don't venture outside its golden.
R is bad building material, but if you dont want to build something novel in the first place (in a statistical or machine learning sense), just call a canned solution on your (medium sized data) data, then R is the boss. If you try to do anything meaty or clever then you have to be careful with R's gotchas. It helps commoditize data analysis and popularize techniques amongst its large base. If you want statisticians to be aware of some cool technique, you have to release an R package, because if it isnt in CRAN it does not exist.
>I disagree with you premise that R is not popular among machine learners
I know what you are saying, and I agree, that is why I chose my words carefully.
I am not so sure about the *scope* of the 'bleeding edge' part
The word I wanted to highlight is "scope". The population that identifies themselves with any of these labels: machine learners, statistician, data scientist, data modeler, actuarial scientist, prediction consultant and all other variations...is huge. So whether R is popular or not depends on whom you want to include and whom you want to exclude.There is a quite a lot of variation here. In one subset, if you know the ins and outs of R you will be taken for a wizard, in another subset just listing R/MATLAB as one of your major skill will actually work against you.
> what's wrong with "pushbutton" libraries?
Nothing at all and I did not claim its wrong either. In fact I said that is one of R's strengths. For people who arent into the theory of statistics or ML then R can be a heaven sent. Especially if all they want to do is try out a catalog of algorithms.
The analogy I use is that of an automobile industry. If your goal is to be a run off the mill automobile driver/chauffeur R is your competitive advantage. If your goal is to be an automotive engineer (design new models and algorithms) R is an inferior tool. In fact if you want to be a F1 racer, you have to look elsewhere too. Like every tool it has its sweet spot, as long you don't venture outside its golden.
R is bad building material, but if you dont want to build something novel in the first place (in a statistical or machine learning sense), just call a canned solution on your (medium sized data) data, then R is the boss. If you try to do anything meaty or clever then you have to be careful with R's gotchas. It helps commoditize data analysis and popularize techniques amongst its large base. If you want statisticians to be aware of some cool technique, you have to release an R package, because if it isnt in CRAN it does not exist.
This is one of the misconceptions about Python, that it's "slow". Python has several type annotation systems with JITing capability, and can easily achieve C-speeds (as well as interface easily to C libraries). We've given two tutorials at Supercomputing in the last two years, and the trend for high performance computing in Python is on the rise. Don't count it out!
Great stuff. I think the author may be using the release version 0.2, as the boot time issue has been rectified now for the most part in the next release, 0.3. The next big slow-load issues is packages, that'll be post 0.3 though.
OP here. I'm currently using 0.2, I'll have to upgrade and see if that fixes the issue. Thanks!
There are two separate issues, I believe you refer to. There is the boot time, which has been considerably improved, and is less than a second. The second thing is the slight pause that you refer to (if I understand the post correctly), when executing stuff the first time. That is the JIT compiling and warming the code cache.
The startup time in 0.3 is more than 10x faster than 0.2 – it's down to ~200 ms on my machine, whereas it was about 2 seconds before. It's now quite painful to go back and use 0.2.
Assuming that this was fixed by caching the machine code, cant the same approach be used for packages ? Or to turn my question around: what is different about packages is it that they are not necessarily written in Julia ?
I have still not taken a serious plunge with Julia, testing waters.
Any plans for doing the same to individual scripts ? It would be handy to start off from the last known set of JIT'ed functions, may be retiring paths that are no longer frequented.
I have still not taken a serious plunge with Julia, testing waters.
Any plans for doing the same to individual scripts ? It would be handy to start off from the last known set of JIT'ed functions, may be retiring paths that are no longer frequented.
Yes - the base image is compiled to a shared library.
There is a mechanism for including package/user code in the system image if you compile Julia yourself. It works well with a wide range of packages, but the goal is to generalize this and make it usable with binary releases, and probably to compile packages to separate shared libraries.
There is a mechanism for including package/user code in the system image if you compile Julia yourself. It works well with a wide range of packages, but the goal is to generalize this and make it usable with binary releases, and probably to compile packages to separate shared libraries.
Is the error reporting improved for 0.3? That was my main problem with 0.2 (on linux). I ran into situations where all I knew was that something went wrong somewhere in my program. I've seen other people make similar comments.
(Aside from that I really love the language, and I'm looking forward to doing more with it.)
(Aside from that I really love the language, and I'm looking forward to doing more with it.)
I'm really excited by Julia. We use Matlab heavily in my team (as in, we probably have 300-600 Matlab instances running at any given time not counting the ones on personal workstations) and I'd love to use a language with similar support for numerical programming and linear algebra, but with better typing and functional programming support.
Do you have any suggestions for slowly introducing Julia to the team?
Do you have any suggestions for slowly introducing Julia to the team?
May I ask what you're doing with all those instances?
And to be extremely bold: what are you paying for all those licenses?
And to be extremely bold: what are you paying for all those licenses?
How is multiple dispatch different from function overloading, as found in C++/Pascal? Is it the same thing?
Dispatch is the process of selecting and executing the matching overload. Multiple-dispatch refers to the ability to select the best overload based on more than just the first argument. C++ can do arity and type-based multiple-dispatch, but only statically. Julia supports dynamic multiple dispatch, where as C++'s virtual methods are only single-dispatch dynamically.
Precisely. This may sound pedantic or academic, but in practice when static overloading and dynamic dispatch differ, the static behavior is usually not what you want. In my experience, this makes it painful to make code that is polymorphic in multiple arguments behave correctly in C++ (double dispatch [1] is one of the necessary but awkward tactics that's used), whereas multiple dispatch just works. And of course, almost working and actually working are a world apart even though they sound so close.
[1] http://lostechies.com/derekgreer/2010/04/19/double-dispatch-...
[1] http://lostechies.com/derekgreer/2010/04/19/double-dispatch-...
Stefan Karpinski wrote a very nice overview of multiple dispatch with many examples and some discussion of design implications:
http://nbviewer.ipython.org/gist/StefanKarpinski/b8fe9dbb36c...
(he gave this as a talk at Strange Loop 2013, but the video seems to still be embargoed)
http://nbviewer.ipython.org/gist/StefanKarpinski/b8fe9dbb36c...
(he gave this as a talk at Strange Loop 2013, but the video seems to still be embargoed)
This may be my fault for not submitting the slides. I haven't figured out how to turn the IJulia notebook into a PDF :-\
I am assuming you have already tried this - but doesn't print and save as pdf do it on a mac?
I think Chrome for other platforms will print to PDF conveniently too.
From playing a bit with the Julia REPL (http://forio.com/julia/repl/), it seems that the dispatch of the method is dynamic, as opposed to the dispatch of overloaded functions in C++:
† Probably more, as the dispatch can be resolved based on many arguments.
julia> function foo(s::String) "$(s)!!!" end
foo (generic function with 1 method)
julia> function foo(n::Int) n + 1 end
foo (generic function with 2 methods)
julia> foo(rand() < 0.5 ? "Hello" : 41)
42
I'm not used to this kind of dispatch for bare functions, but it seems to me that it could offer similar capabilities to what subtype polymorphism provides in OO†, without having to define new types for this methods to live in or polluting the existing types.† Probably more, as the dispatch can be resolved based on many arguments.
[deleted]
What's the deal with the lack of conditionals in comprehensions? Is there a good reason that the Julia devs didn't include that, or is it just something that's not been implemented yet?
Edit: after a little searching, I found this.
> Filters and guards don't mix with multidimensional comprehensions. For 1-d comprehensions, I'm not convinced that it's really worth the additional syntax. What's the case for making it part of the syntax instead of just using a filter function?
Edit: after a little searching, I found this.
> Filters and guards don't mix with multidimensional comprehensions. For 1-d comprehensions, I'm not convinced that it's really worth the additional syntax. What's the case for making it part of the syntax instead of just using a filter function?
Julia's comprehensions are multidimensional array comprehensions so allowing filtering doesn't make much sense because the result needs to be rectangular and filtering can create arbitrary holes.
For a one-dimensional array comprehension it does make sense to allow filtering and this can be easily expressed in Julia by making a coroutine that produces the values and collecting its output in an array.
Multidimensional (here multi=2) array result:
For a one-dimensional array comprehension it does make sense to allow filtering and this can be easily expressed in Julia by making a coroutine that produces the values and collecting its output in an array.
Multidimensional (here multi=2) array result:
julia> [i+j for i=1:3, j=1:3]
3x3 Array{Int32,2}:
2 3 4
3 4 5
4 5 6
One dimensional array result, with filtering: julia> collect(@task for i=1:6; if i%3>0; produce(i); end; end)
4-element Array{Any,1}:
1
2
4
5
Notice that this last technique is more powerful than typical comprehensions, since it doesn't just add the possibility of filtering but arbitrary code to generate the elements.Thanks for the further info! I'd managed to figure out that it was because of multidimensional arrays (that snippet I quoted) but I didn't immediately see a nice way to achieve the same thing. And now, because you posted it, I do.
I'll have to give Julia a go. :)
I'll have to give Julia a go. :)
I was interested in Julia until I discovered that it doesn't allow useful things like object-oriented inheritance (unless you go down some complex metaprogramming route). Multiple dispatch is indeed cool, but for some types of systems modelling with inheritance and classes is a great or the best approach (e.g. GUI widget libraries). I thought about how you might wrap something like Qt, gave up, and decided to continue with lovely Python (and its lovely 0 based indexes).
Single inheritance is possible and used extensively in Julia. Multiple inheritance is not (currently) supported, and there are a few places where it would be useful, but it is surprising that this would be a show stopper.
I'm not sure it's the single inheritance people from other languages might understand. Perhaps I'm misunderstanding things as I've hardly used the languages, but there are links like http://thenewphalls.wordpress.com/2014/03/06/understanding-o... and http://grollchristian.wordpress.com/2014/01/22/julia-inherit... and https://github.com/JuliaLang/julia/issues/4935
Sure, but that is a different thing than "not object-oriented inheritance". Designing with Julia's types and multiple-dispatch is different, but there are some nice patterns emerging.
That said, Julia is still developing. The kinds of people who are interested in Julia right now are probably different from the people who we hope to attract and be broadly useful for in 2-5 years. But feedback now is important so the language and ecosystem can get there!
That said, Julia is still developing. The kinds of people who are interested in Julia right now are probably different from the people who we hope to attract and be broadly useful for in 2-5 years. But feedback now is important so the language and ecosystem can get there!
I've been following Julia for a while now, not really using it, but playing with it a bit and keeping up with it. I think it's very promising and I really look forward to seeing it fledged out more.
It's a very small nitpick, but I wish Julia had a postfix function application syntax. It would be nice to be able to say `foo = 'hello'.reverse` and have it be syntactic sugar for `foo = reverse(hello)`. Or some other operator since `.` is in use. This reads nicer for long function chains, and especially when a function modifies its argument, it's nice to have that argument come first, which gives an OO-impression. E.g. for me this:
It's a very small nitpick, but I wish Julia had a postfix function application syntax. It would be nice to be able to say `foo = 'hello'.reverse` and have it be syntactic sugar for `foo = reverse(hello)`. Or some other operator since `.` is in use. This reads nicer for long function chains, and especially when a function modifies its argument, it's nice to have that argument come first, which gives an OO-impression. E.g. for me this:
app = make_app(options)
app.route("/", _ -> "hello, world!"),
app.route("/submit", POST, req -> "hello, $(req.params["name"])!")
app.start(3000)
than this: app = make_app(options)
route(app, "/", _ -> "hello, world!"),
route(app, "/submit", POST, req -> "hello, $(req.params["name"])!")
start(app, 3000)There is this, which is similar but not quite the same:
julia> "hello" |> reverse |> uppercase
"OLLEH"Julia looks like a wonderful mix of Ruby, Python and ML (or something). I'm really eager to see this adopted by more people.
People who are using Julia or similar tools to do "scientific computing, machine learning, data mining, large-scale linear algebra, distributed and parallel computing" - what sort of problems are you solving? How did you end up doing this sort of work?
Hmm, I was hoping for some impressions of using Julia for numerical computing. The mechanics of list comprehensions and uppercasing some text seem a little tangential.
That's an important part of Julia, but it's also important to talk about the language as a language. One of nice things about Julia is that it has things to talk about other than its numerical computing capabilities :) Those are fine and dandy, but as a non-numerical-computer, I find lots to like about Julia that has nothing to do with its ability to multiply matrices.
I too am intrigued by julia based off of my brief interactions with it. My only issue is the lack of namespaces. Is there a good reason why they aren't included?
They are: http://docs.julialang.org/en/latest/manual/modules/
Or is that not what you were referring to?
Or is that not what you were referring to?
If I can ask a stupid question. Why Julia? It seems to me that if you are not going to be using Python, then why not use a language like Java?
Huh, what upside does Java have?
Julia is specifically designed to be a great high-performance high-level language for scientific computing. See http://julialang.org/blog/2012/02/why-we-created-julia/
Julia is specifically designed to be a great high-performance high-level language for scientific computing. See http://julialang.org/blog/2012/02/why-we-created-julia/
public class Answer {
public static void main(String[] args) {
public static void main(String[] args) {
System.out.println("That's why");
}
}A lot of people doing scientific programming are not, in many senses of the word, 'programmers', and java doesn't really fit in the kinds of workflow they want. (That's not a condemnation, it's just the way it is, see also the ghosts of fortran 77)
At the beginning of this article: "I spent most of last night programming in Julia and I've got some thoughts on my first impressions. TL;DR: It's like Python with less OOP, more FP and heavier typing. Also, it's awesome."
--------------------------------
Then I clicked on the site's about: "Welcome to Eyeball Trees. My name is Stephen Malone and I cannot be trusted."
I'm really confused!
--------------------------------
Then I clicked on the site's about: "Welcome to Eyeball Trees. My name is Stephen Malone and I cannot be trusted."
I'm really confused!
https://github.com/ninjin/ppod/tree/master/hck/rnn_perf
Disappointingly enough I was unable to push the performance of Julia beyond that of pure (and ugly) Matlab. I tried asking over at #julia, but it seems that my implementation should be reasonably canonical. This is really a pity for me since I would love to remain highly productive in terms of code and use something scripting-esque rather than have to re-consider going back to C. I have also had a look at Nimrod, but the scientific library support appears somewhat lacking at the moment.