Slashdot Mirror
Julia Language Seeks To Be the C For Numerical Computing
concealment writes in with an interview with a creator of the (fairly) new language Julia designed for number crunching. Quoting Infoworld: "InfoWorld: When you say technical computing, to what type of applications are you specifically referring? Karpinski: It's a broad category, but it's pretty much anything that involves a lot of number-crunching. In my own background, I've done a lot of linear algebra but a fair amount of statistics as well. The tool of choice for linear algebra tends to be Matlab. The tool of choice for statistics tends to be R, and I've used both of those a great deal. But they're not really interchangeable. If you want to do statistics in Matlab, it's frustrating. If you want to do linear algebra in R, it's frustrating. InfoWorld: So you developed Julia with the intent to make it easier to build technical applications? Karpinski: Yes. The idea is that it should be extremely high productivity. To that end, it's a dynamic language, so it's relatively easy to program, and it's got a very simple programming model. But it has extremely high performance, which cuts out [the need for] a third language [C], which is often [used] to get performance in any of these other languages. I should also mention NumPy, which is a contender for these areas. For Matlab, R, and NumPy, for all of these options, you need to at some point drop down into C to get performance. One of our goals explicitly is to have sufficiently good performance in Julia that you'd never have to drop down into C."
The language implementation is licensed under the GPL. Lambda the Ultimate has a bit of commentary on the language, and an R programmer gives his two cents on the language.
I use Sage quite a bit. It's basically a wrapper for almost all the mathematics software available. http://www.sagemath.org/ While you still need to drop down to C for great performance, it solves a lot of the interoperability issues discussed. In other words, take the example from the summary: from Sage, you can call Matlab commands and then immediately use the results with R commands. Sage works through a web browser, and it's based on Python, which is a plus.
Three days from now?? Thats tomorrow!! ~Peter Griffin
In my opinion, the new code in Julia is easier to read than the R code because Julia has fewer syntactic quirks than R. More importantly, the Julia code runs much faster than the R code without any real effort put into speed optimization. For the sample text I tried to decipher, the Julia code completes 50,000 iterations of the sampler in 51 seconds, while the R code completes the same 50,000 iterations in 67 minutes — making the R code more than 75 slower than the Julia code.
That certainly caught my attention!
The XKCD comic you cite is correct for some standards but software languages are much more complex than standards and, in fact, many of them implement common sets of core standards. Once you get specific enough, you're not talking about a standard but rather a specific implementation of how to accomplish something.
My work here is dung.
From wikipedia: "FORTRAN is a general-purpose, procedural, imperative programming language that is especially suited to numeric computation and scientific computing." Sounds to me like unless there's a particular weakness in FORTRAN that doesn't lend itself to workarounds or repair in newer versions of the language, there's already a numeric computation and scientific programming language that's well documented, mature, and widely distributed.
Do not look into laser with remaining eye.
You're funny. Both of these depend largely on the programmer writing the code.
What will make or break this language is the availability of addon packages for it. A lot of people who use R don't do much coding themselves. They read in data, preprocess it a little bit, and then apply one of the packages found in CRAN.
CRAN is like CPAN, but for R instead of Perl. And we can expect similar behavior from them. Perl probably wouldn't be anyone's first choice for a project these days, but the size and scope of CPAN makes it really really easy to benefit from the work of others. This is a lot of inertia, and a big reason why Perl is still used when newer languages have significant advantages.
There's so much software, particularly academic software, implemented in R that I just don't see it going away. e.g. the entire Bioconductor suite is implemented in R. Just about any bioinformatics paper you pick at random will refer to, if not contain R code.
How much work are we going to have to reimplement if we want everyone to use the one true numerical programming language? And if we don't want that, isn't it just contributing to fragmentation?
Give me Classic Slashdot or give me death!
Robust, mature, fast, easy to use, side-by-side with .m it wins hands down, really no comparison, use Python.
Cython if you need to make it faster for the %5 of code that is too slow.
import numpy
import pylab
If you aren't writing readable and maintainable code in C that's the programmer's fault. You aren't forced to use obscure abbreviations, bizarre inline hacks, etc. There is plenty of readable and well-maintained code that has been running non-stop longer than your modern langauges have existed.
What is that a hash of the source code?
Careful... wouldn't want to give the Mozilla devs any ideas.
Fear is the mind killer.
The other obvious language to come to mind is APL. Anyone looking to write a numerical processing language should have some APL experience.
Yes, it is a pain to learn all the symbols. Programs are incredibly dense, making them difficult to understand and debug, but there are also a lot of cool things you can do with the language. In building a new language, there's a lot of good stuff there to incorporate.
Never seen a successful language named after a person. Probably never will.
There aren't that many, and the few there are seems to have been fairly successful. At the top of my head, I can think of Pascal, Ada Eiffel, Haskell and Ruby.
At least Pascal had a huge impact. p-code was the frontrunner for bytecode. I'd say it dwindled because of Borland who played fast and loose with the standards, reducing its main strength of being incredibly strict and compatible for a visual IDE and proprietary extensions (Delphi). This gave it a short term flare, but probably helped kill it in the long run.
The weakness of FORTRAN is that it entirely misses out of 50+ years of research and innovation in programming languages.
OK, maybe the original version of Fortran, the one made 50+ years ago, missed out on "50+ years of research and innovation in programming languages", but you are aware that Fortran has been updated since then, right?
Fortran now includes a great number of the improvements to programming languages made since then. But don't take my word for it -- check out Wikipedia's page on it. I picked Fortran 90 as a starting point, but there's been many versions of Fortran made since the first, with new features (often coming from other languages) being added all the time.
And not only is Fortran still being actively developed, but the library of well tested and optimized numerical computing code already written it it is massive.
I'm not saying that there's not room for a new language, and certainly, Fortran doesn't have all the features of some new languages, but your claim that Fortran "entirely misses out of 50+ years of research and innovation in programming languages" is completely and utterly wrong.
I should also mention that they stopped calling it FORTRAN in all caps back in 1990 or so when Fortran 90 came out. Now it's just Fortran. But even the venerable FORTRAN 77 benefited greatly from programing language developments available at the time.
It could be argued that Ada not only had a huge effect (many language features we now thing of as standard came from Ada), but is still in use in many places, so I would call it pretty successful.
The problem is that a lot of researchers and scientists who write these things aren't trained in good programming practices, and most of the good programmers don't have the background to do a lot of the advanced math stuff properly.
In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
The problem with C++ is that it has too many features, and too many ways to do the same thing. You can write complex application programs in C++ while only knowing a small subset of the language. The problem ocurs when someone comes along to maintain your code and knows a completely different subset.
They want to design a language for speed, but they already made choices in the language that hamper speed dramatically, like dynamic typing. Dynamic typing adds overhead to every function call; it's fine if your functions do a lot of work, not so much if they do relatively little and are called very often.
It looks like if you want to write fairly low-level code, you'll still need to write it in C there...
It also looks like their approach to parallelization is very heavy-weight and, albeit usable in clusters, it will yield both poor scalability on large systems and poor performance on simple multi-core systems.
There is already a high-level, dynamic and accessible language for numerical computing, it's MATLAB. It wraps a lot of high-performance libraries, using them without the user even noticing it. Code in MATLAB can easily be faster than in C for some constructs because C compilers, unlike MATLAB, do not recognize some patterns and replace them by optimized library calls. For this reason, MATLAB is great when you're coding with high-level constructs, but suffers from poor performance when using low-level constructs (such as accessing data element by element) for the same reasons as pointed out above.
A new language for high-performance numerical computing should allow both the high-level programming of MATLAB and the possibilities of a low-level statically compiled language like C. The best contender for this is C++, which has tons of high-level and fast libraries for transcendental functions, linear algebra, statistics, image processing, signal processing, etc.
As for FORTRAN, it's great for writing one thing well and fast, but it doesn't have any mechanisms for more high-level programming or code re-use, which means it is annoying to maintain, extend, or to even guarantee consistencies between the different subroutines of a large application. It also relies a lot more on what the compiler will do, while with C/C++ there is more control on what happens with regards to vectorization, parallelization or data transfers, which can be critical for heterogeneous systems.
Then again, most of it is written by biologists.
You mean 'evolved by biologists'. They aren't strong believers in intelligent design.