Become a fan of Slashdot on Facebook


Forgot your password?
Math Programming Stats

Julia Language Seeks To Be the C For Numerical Computing 204

Posted by Unknown Lamer
from the two-parts-fortran-one-part-lisp dept.
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.
This discussion has been archived. No new comments can be posted.

Julia Language Seeks To Be the C For Numerical Computing

Comments Filter:
  • by Anonymous Coward on Wednesday April 18, 2012 @09:51AM (#39722879)

    You mean, ignored by almost every developer in the field in lieu of more "business-friendly" languages that add bloat and inefficiency?

    As well as maintainability, readability, etc.

  • by BenoitRen (998927) on Wednesday April 18, 2012 @10:01AM (#39722979)

    As well as maintainability, readability, etc.

    You're funny. Both of these depend largely on the programmer writing the code.

  • by Lunix Nutcase (1092239) on Wednesday April 18, 2012 @10:13AM (#39723077)

    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.

  • Re:FORTRAN? (Score:3, Insightful)

    by Anonymous Coward on Wednesday April 18, 2012 @10:14AM (#39723083)

    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.

    Yes, you have to be concerned when someone talks about numerical computing and mentions C but skips FORTRAN.

    The GNU FORTRAN compiler is quite good (and free), but the $$$ compilers (such as the Intel FORTRAN compiler) are needed to get the speed you need to outperform other languages. Simply put, it costs serious money to do high-end professional FORTRAN development - something that is hard to take if you are coming from a background where compilers are free.

  • Re:FORTRAN? (Score:3, Insightful)

    by Anonymous Coward on Wednesday April 18, 2012 @10:16AM (#39723101)

    People use FORTRAN largely because it's tried and tested. We know how to code it, we know the quirks, we know how to cope with rounding issues and so forth. Similarly C is a powerhouse because fundamentally it's a simple language and it's very, very well understood. That counts a lot more for speed, in many cases. Nowadays with vast parallelisation becoming cheap, it is generally better to stick with code that you know works and trade off individual thread efficiency for strength in numbers.

    Note there's a subtle difference between people using legacy code because they're lazy and the infrastructure is there and people using legacy code because they know it works, even if there is a potentially better alternative.

    Air traffic control in the UK still runs on computers using Pentium hardware and probably won't change for at least another 10 years because when you're developing critical systems you need to know that what you're doing is robust.

  • APL? (Score:4, Insightful)

    by crow (16139) on Wednesday April 18, 2012 @10:24AM (#39723169) Homepage Journal

    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.

  • Re:Not This Again (Score:4, Insightful)

    by AchilleTalon (540925) on Wednesday April 18, 2012 @10:48AM (#39723441) Homepage

    Anyway, this language isn't for you. That's a specialized language for numerically intensive applications and if you have a clue about what it is, you would found this language very easy to learn. It is almost the same as all the tools (Matlab/Octave) currently used in these fields and for teaching. You aren't expected to write a Web browser in Julia.

    The performance/ease of use is the appropriate balance in this field. Usable in almost no time.

  • by swan5566 (1771176) on Wednesday April 18, 2012 @11:09AM (#39723719)
    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.
  • by danfromsb (965115) on Wednesday April 18, 2012 @11:30AM (#39723965)

    Absolutely right. It is important to recognize that both Matlab and R are much more than just languages. I would also throw Mathematica into the mix too, while it is a bit slower than Matlab, its numerical capabilities have continued to grow and it incorporates a fine statistics package alongside a quality plotting and graphics package (not to mention its symbolic roots and recent introduction of dynamic gui manipulation).

    For julia to be successful it needs robust integration with quality addon packages, starting with graphics and plotting. It also needs good documentation. One thing that annoys me to no end with Python (and numpy, scipy, pylab, matplotlib) is that you have to look at 3 or 4 different websites to look up API and examples. In my mind Mathematica does this right: a single documentation library which incorporates API reference, tutorials, and common functions grouped together. At the bottom of every page it lists related functions and tutorials so it is easy to discover new API calls in the language.

  • by Vegemeister (1259976) on Wednesday April 18, 2012 @11:33AM (#39724005)
    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.
  • Re:Not fast at all (Score:3, Insightful)

    by Baron von Leezard (675918) on Wednesday April 18, 2012 @02:37PM (#39726677)

    Dynamic typing doesn't add any overhead when you can determine which specific method you need when generating code — which, in a dynamic language with a JIT, is very late, meaning that you can most of the time. Julia uses tons of small method definitions that call other small methods and so on, even for basic things like adding two integers, but the compiler is smart enough to compile addition into a single machine instruction. The notion that dynamic languages are slow because of their dynamism is very outdated in light of modern compiler techniques.

"Paul Lynde to block..." -- a contestant on "Hollywood Squares"