Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Math Programming Stats

Julia Language Seeks To Be the C For Numerical Computing 204

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

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

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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.

      • Re: (Score:3, Insightful)

        by BenoitRen ( 998927 )

        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.

        • by jythie ( 914043 )
          Just like C++

          C++ has so many little geeky features, behaviors, and stylest in it that writing unintelligible (except to a few 'l33t') code is pretty on-par with C.
          • 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.
        • 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 Surt ( 22457 )

      Yes, all those businesses are choosing their languages in order to be uncompetitive with those that choose to implement their projects in C. And they are being run out of the market by their swifter competitors!

      Or in other words: contrary to your opinion, the facts are in, and those other languages are proving superior to C.

      • by arth1 ( 260657 )

        Yes, all those businesses are choosing their languages in order to be uncompetitive with those that choose to implement their projects in C. And they are being run out of the market by their swifter competitors!

        Or in other words: contrary to your opinion, the facts are in, and those other languages are proving superior to C.

        Ah, the bandwagon fallacy. I wondered when it would come up.

        The problem is the definition of "superior". Most businesses are interested in getting the job done, and will use whatever is readily and cheaply available. What's superior has little or nothing to do with it, and in most cases isn't even known to those buying the work.

        • Funny, my definition of "superior" would be a language that gets the job done, and is readily and cheaply available.

        • While I'm not about to argue that popularity == superiority, if there's some trend showing that companies using language X are generally more profitable than those using language Y, then language Y may well be the right tool for the job, and at least the superior choice.

        • by Raenex ( 947668 )

          Most businesses are interested in getting the job done, and will use whatever is readily and cheaply available.

          You can't argue that C isn't readily or cheaply available -- it is. Businesses switched away from C and C++ because they are too error prone and low-level, meaning programmers aren't as productive.

          Now what usually happens is to blame the programmers, or not hiring smart enough programmers, as if the programmers are there to serve the language rather than the other way around.

        • by Surt ( 22457 )

          My definition for success is success. C projects are getting beaten by other languages in the marketplace .

  • Sage (Score:5, Informative)

    by donaggie03 ( 769758 ) <<d_osmeyer> <at> <hotmail.com>> on Wednesday April 18, 2012 @09:55AM (#39722913)
    I use Sage quite a bit. It's basically a wrapper for almost all the mathematics software available. http://www.sagemath.org/ [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.
  • What is that a hash of the source code?

    • by ifrag ( 984323 ) on Wednesday April 18, 2012 @10:16AM (#39723097)

      What is that a hash of the source code?

      Careful... wouldn't want to give the Mozilla devs any ideas.

    • Without reading TFA (a GPL'd reference implementation of a new language? Good luck with that.) it's probably a git version. The designers of git come from a planet whose dominant species did not evolve a concept of linear orderings until quite late in their development and so identify sequences by unrelated names of each value.
      • It's not git specific, all distributed versioning systems use hashes for versions.

        • No, all distributed versioning systems use hashes for changesets. Fossil and Mercurial - distributed system systems designed by and for humans - use a monotonic counter for version numbers.
  • FORTRAN? (Score:5, Interesting)

    by TWX ( 665546 ) on Wednesday April 18, 2012 @09:59AM (#39722957)
    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.
    • by Hentes ( 2461350 )

      The main strength of this language seems to be easy paralellisation, which can lead to higher speeds for certain algorithms.

      • Doesn't modern FORTRAN have that?
        • Re:FORTRAN? (Score:4, Informative)

          by Bill_the_Engineer ( 772575 ) on Wednesday April 18, 2012 @10:33AM (#39723257)
          Yes and is used extensively. There are even C libraries that include FORTRAN code to numerical work quickly.
        • Re:FORTRAN? (Score:5, Informative)

          by gl4ss ( 559668 ) on Wednesday April 18, 2012 @11:38AM (#39724081) Homepage Journal

          well.. apparently this "language" has modern fortran built in.

          just open the link. there's some stats there. I don't envision huge popularity for this though.. unless he integrates/develops it into a fullblown mathlab competitor(that javascript does mandelbrot almost as fast is kind if peculiar though..). not as peculiar as "pi sum" bench being faster on javascript and julia than c++.

          "The library, mostly written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, FFTs, and string processing. "

    • Re:FORTRAN? (Score:5, Interesting)

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

      Second that. Modern FORTRAN kicks some serious butt and has a huge user and support base. Language snobs dismiss it as antiquated but they're usually referring to versions of the language that haven't been used since the 1980's. There are good reasons that current HPC developers use mostly FORTRAN and C, like good support for parallalization, global memory functions for clustering, and efficient compilers.

      It's great that people make new tools and share them with others, but many times that effort could be put into making existing good tools even better.

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        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

        • I work with people who use FORTAN because it's not only tried and tested but also the fastest for numerical computing.
          • The main complaint against FORTRAN and C and even C++ is that because they're compiled languages, debugging is more of an effort than it is in a MATLAB script, where individual lines of code can be executed with a single mouse click. For Big Data number crunching, it actually doesn't make a bit of difference, because your program isn't going to change in the middle of a dataset, the way it might when you're just debugging or dabbling.

            I should also say that MATLAB, R, and all the rest are real programming
      • Re:FORTRAN? (Score:4, Interesting)

        by ahoffer0 ( 1372847 ) on Wednesday April 18, 2012 @11:36AM (#39724049)

        I attended SC11 (sc11.supercomputing.org) last year. FORTRAN is still the work horse of (large-scale) numerical computing. C/C++ are popular. So are MATLAB and R. They was even a NumPy tutorial and some sessions on emerging languages like Chapel. But FORTRAN was king.

        I thought this was an interesting thread about FORTRAN v. C -- http://www.physicsforums.com/showthread.php?t=169974 [physicsforums.com]

        Off-topic:When it came to programming, the general drift of the conference was not toward new languages, but toward adding meta-information, vis-a-vi compiler directives.

      • Second that. Modern FORTRAN kicks some serious butt and has a huge user and support base. Language snobs dismiss it as antiquated but they're usually referring to versions of the language that haven't been used since the 1980's. There are good reasons that current HPC developers use mostly FORTRAN and C, like good support for parallalization, global memory functions for clustering, and efficient compilers.

        It's great that people make new tools and share them with others, but many times that effort could be put into making existing good tools even better.

        Hmm. Ok, the last FORTRAN I used in anger was FORTRAN77, but I've have a skim of some online tutorials and although the more recent versions are certainly better they still don't look like modern computer languages. Maybe I'm missing something because I could only skim the tutorials. Does modern FORTRAN support delegates? Anonymous functions? Closures? Reflection?I see that it now has some OO support, but how good is it? Yes, if you are doing number-crunching it is probably a good alternative to C as a low-

    • by Dr. Tom ( 23206 )

      People who have to look up FORTRAN on Wikipedia to find out what it is have no business recommending it.

      • by TWX ( 665546 )
        Yeah, because I remember all of the relevant details of a programming language that I know is still in active use on lots of big iron computers and can more eloquently describe it than an article that might actually have been written by professionals, or at least enthusiasts.

        My point is that there are languages that are mature that are capable of doing a lot of what people actually want to do already. If there are weaknesses in that language, a discussion on why replacing that language with another is h
        • by rmstar ( 114746 )

          My point is that there are languages that are mature that are capable of doing a lot of what people actually want to do already. If there are weaknesses in that language, a discussion on why replacing that language with another is helpful.

          In my experience, this type of discussion is rarely helpful.

          I like C++, even though I like C, because at least C++ chose to address some issues in C and improve upon them, rather than going, "I HATE C! I AM GOING TO WRITE A WHOLE NEW LANGUAGE!"

          You know, I like C. But I thi

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

      • by Zordak ( 123132 )
        Of course, there's no evidence that the free Julia will be any better. And Julia doesn't have the advantage of 50-ish years of people understanding it. But I agree with that anybody who blabbers about numerical methods and mentions C but not FORTRAN worries me.
    • Well you beat me to the post but yes Fortran 90 and beyond have all the features of "modern" languages and quite a bit more that are not found in other languages du jour. Instead of mocking people might do well to familarize themself with the current language and not keep talking about IV or 77.

    • Fortress (Score:2, Interesting)

      by l00sr ( 266426 )

      The weakness of FORTRAN is that it entirely misses out of 50+ years of research and innovation in programming languages. My gripe with Julia is that it seems to be based on Common Lisp, which itself is pretty old at this point. Fortress [wikipedia.org] seems like a better Fortran replacement to me, since it is actually based on modern functional programming languages. I mean, really, what's the point of releasing a new language based on outdated tech when better alternatives are available?

      • Forgot to mention the irony that one of the principal architects of Common Lisp was Guy Steele, who is now developing Fortress.

        • by gazuga ( 128955 )

          Offtopic, I know, but was there ever a more manly name than 'Guy Steele'? That may be better than Max Power, even.

      • by arth1 ( 260657 )

        Because new doesn't imply better. Sometimes something survives because it is good..
        We still drive automobiles. They have improved over time, just like Fortran has improved over time too. But my car still has four wheels, an engine, pedals and a steering wheel - it's an automobile, and damn useful even 120 years later.
        Sure, jet fighters, snowboards and Segways are newer technology, and well suited for their uses. But to get me from where I am to the neighboring town, a car is much faster. Neither of the

      • Re:Fortress (Score:5, Informative)

        by dougmc ( 70836 ) <dougmc+slashdot@frenzied.us> on Wednesday April 18, 2012 @10:55AM (#39723529) Homepage

        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 [wikipedia.org]. 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.

      • by plopez ( 54068 )

        I'm getting tired of saying this. Check out Fortran '08. Fully OOP.

    • 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 [wikipedia.org]. 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.

      • "Yes, it is a pain to learn all the symbols."

        And its impossible to enter a lot of them on most keyboards. That makes the language useless for almost everyone.

        • by arth1 ( 260657 )

          For small values of "almost everyone". It's still in use.
          And if you can't get an APL compatible keyboard layout, there's J, which was (at least in part) made for APL coders without APL compatible keyboards. All hail J.

        • by crow ( 16139 )

          Impossible? No. It requires some interesting keyboard mappings and a template to make sense of it (which is how I learned it).

          And the point of my post was not to say that APL is a good solution, but that anyone designing a number processing language should learn it so that they can incorporate the ideas into whatever language they're creating.

    • by redelm ( 54142 )

      The very limitations of FORTRAN control flow, especially around DO - loops are things that make vectorization easier which keeps FORTRAN very viable for numeric processing.

    • by jythie ( 914043 )
      Not only that, but compiling FORTRAN and C (and thus C++) into the same application is easy ^_^

      FORTRAN has a bad rep.. it is a good language, but not very 'sexy', so it has fallen out of favor. Languages are, in many ways, a social contest... often having more to do with how many people are using it then the language's actual ability (since this impacts how easy it is to hire people).

      Unfortunately there is also a high 'sexy' factor in creating new languages that do the same things as old ones, solving t
  • by Hatta ( 162192 ) on Wednesday April 18, 2012 @10:06AM (#39723015) Journal

    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?

    • by Hentes ( 2461350 )

      Even the article mentions that most of the other languages use C code. Dynamic languages tend to have good foreign function interfaces, and this one seems to have one too [julialang.org]. The only thing that has to be reimplemented is a wrapper if you want a friendly interface.

    • http://pdl.perl.org [perl.org] does lots of math and is still going strong...
    • Re: (Score:3, Insightful)

      by danfromsb ( 965115 )

      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, st

    • I could not agree more.

      Let's face it, Perl is an abysmal language by itself. (Yes, the regex engine is good, but that's about it IMHO.) Add in CPAN though, and you've got a massive wealth of libraries to use. The pain becomes worthwhile.

  • Numerical Python (Score:5, Informative)

    by Dr. Tom ( 23206 ) <tomh@nih.gov> on Wednesday April 18, 2012 @10:09AM (#39723045) Homepage

    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

    • I mostly use python these days, mainly to work with FEniCS. I really don't like the syntax, though. Matlab's syntax is just so slick by comparison:

      Matlab: foo = [1 2;3 4] Python: foo= array([[1,2],[3,4]]) R: foo - matrix(c(1,2,3,4),2,2)

        A numerical language should be able to do simple tasks like this with as few keystrokes as possible.

      • by waives ( 1257650 )
        Two words: list comprehensions. Suck it matlab.
      • by plopez ( 54068 )

        R: foo-matrix(c(1:4),2,2)

        That's how I would do it.

        You use sequences and lists a lot in R. Part of the Lisp heritage.

        • I think you totally missed the point. You can use sequences and lists in Matlab too, try to imagine it with different numbers.

      • by wfolta ( 603698 )

        At the very lowest level, Matlab is appealing, as in your example. Beyond that, it's a horrible language, lacking features that S and other languages had 20+ years ago.

      • by aisaac ( 247911 )

        I mostly use python these days [snip] Matlab's syntax is just so slick by comparison:

        Matlab: foo = [1 2;3 4] Python: foo= array([[1,2],[3,4]]) R: foo - matrix(c(1,2,3,4),2,2)

        NumPy includes a matrix library: foo=mat('1 2;3 4'). In general, Python's syntax beats Matlab's syntax
        hands down. (In this particular case there is almost a tie, but a trivial advantage for Matlab. I spend apporximately 0% of my time typing in data for array construction, and I suppose that is true of most users.) For help transitioning, see http://www.scipy.org/NumPy_for_Matlab_Users [scipy.org].

    • by daid303 ( 843777 )

      just throw your whole project in pypy, woop, instant speed boost. (in my case 4-5x faster)

  • Beard Ref [khason.net]

    Also is this named after the same Julia that worked with fractals? Julia Ref [wikipedia.org]
  • by GlobalEcho ( 26240 ) on Wednesday April 18, 2012 @10:17AM (#39723107)

    This may seem petty, but one of the biggest sources of relief to me in changing from Matlab to R and Numpy was finally leaving behind that damned operator syntax where element-wise operations need to have an extra dot prepended. That is to say, if I have an array t of times and an array x of distances, I want to be able to get the corresponding array of speeds using x / t. In Matlab and Julia I must instead use x ./ t.

    It seems like no big deal, but it is unbelievable how many Matlab bugs I wrote due to that little difference. True linear algebraic operations are so rare, at least to me, that I am far happier giving them the special operators and reserving the usual operators to work element-wise.

    I also must have named arguments and default values. It's a pity, because otherwise it looks to have decent syntax, good speed and nice parallelization. For now, I'm sticking with R, numpy and C.

    • MATLAB was originally called matrix laboratory. It was created for working with matrices. Therefore, when you tell it to multiply or divide its default is matrix multiplication and division. If you want it to do element-wise operations, you have to tell it specifically to do so.

      Although I agree, it's a PITA as most people don't use its matrix handling capabilities.
  • The Matlab Statistics Toolbox seems pretty good to me, though I don't use R, and I don't do a ton of statistics. Can anybody comment on what makes it frustrating (besides trying to use the output of the code to produce a publication-quality figure)?
  • If you read the article, JavaScript is competitive with Julia in most of the Benchmarks.

    So why yet another language.

    It even looks vaguely like JavaScript, so why bother?

  • This looks like it might be a nice language for general-purpose use, too. It's got a nice blend of features borrowed from other languages such as Haskell-style data structures, Perl-style regular expressions, first-class functions, and of course powerful numerical manipulations. I might have to try it out next time I get fed up with Perl.

    • That's what I was thinking. I'm pretty happy programming in Python 90% of the time, but high-performance code and highly parallel code tends to end up as a sequence of hacks of varying degrees of cleverness. A similarly elegant language that runs 5 to 10 times faster could be very attractive.

      New we just need to wait ten years for the standard library to evolve....

  • Looks neat, I'd like to try it.

    The website mentions how to call C functions from julia...Is there any way to do the oppisite? I'd like to try a julia library from a C program.

    • by plopez ( 54068 )

      Good question. Anything that can be compiled to a library can be called by C, so if Julia can be compiled to a library gcc should be able to link it.

  • C : GeneralPurposeProgramming :: Fortran : Numerical Computing The title of the post is off, or misleading, or ignorant.
  • by mjwalshe ( 1680392 ) on Wednesday April 18, 2012 @01:30PM (#39725631)
    "(Did we mention it should be as fast as FORTRAN?)"
  • Not fast at all (Score:4, Informative)

    by loufoque ( 1400831 ) on Wednesday April 18, 2012 @02:21PM (#39726419)

    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.

    • Re: (Score:3, Insightful)

      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 ve

Maybe you can't buy happiness, but these days you can certainly charge it.

Working...