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.

Comments

The "C" for some field?

[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:The "C" for some field?

[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:The "C" for some field?

[BenoitRen]

As well as maintainability, readability, etc.

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

Re:The "C" for some field?

[Lunix Nutcase]

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:The "C" for some field?

[arth1]

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.

Re:The "C" for some field?

[Surt]

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.

Re:The "C" for some field?

[jythie]

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.

Re:The "C" for some field?

[jythie]

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.

Re:The "C" for some field?

[swan5566]

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.

Re:The "C" for some field?

[plopez]

Like C#?

Re:The "C" for some field?

[arth1]

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.

Re:The "C" for some field?

[StikyPad]

While C certainly has it's flaws, maintainability isn't inherently one of them.

Re:The "C" for some field?

[Vegemeister]

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:The "C" for some field?

[claytongulick]

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

Re:The "C" for some field?

[StikyPad]

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.

Re:The "C" for some field?

[Samantha Wright]

As well as maintainability, readability, etc.

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

You're funny. Maintainable, readable, etc. code is mutually exclusive with numerical computing.

Re:The "C" for some field?

[Rakishi]

So you need to pick your hires by actual skills, not some bullet points on their resumes. Big deal.

You've never had to hire someone, have you?

Re:The "C" for some field?

[Raenex]

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.

Re:The "C" for some field?

[Surt]

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

Re:The "C" for some field?

[CSMoran]

You're funny. Maintainable, readable, etc. code is mutually exclusive with numerical computing.

Not necessarily.

In serious number-crunching the bottlenecks tend to be localized and the 'typical' paths through the code are easier to establish. Profiling is used routinely in the field to identify hot spots. These hot spots are usually algebra, which can be offloaded to BLAS, LAPACK, FFTW and the like, or something that is easily vectorizable, where things like VML are of help. In any case, one can mostly avoid making a mess of the code with loop unrolling and trying to be more clever than an optimizing compiler. The vast majority of the code can then be written in a readable and maintaintable fashion. The programmers must be competent enough not to pass by value, ensure cache-friendliness and so on.

The only readability nightmare is that the code is peppered with #ifdef VENDOR, #pragma omp, !$acc and the like. I prefer to turn the contrast down in the editor for these, almost to the level of comments.

Re:The "C" for some field?

[Samantha Wright]

I want to live on your planet. Every piece of numerical computing code I've ever seen is... well, discouraging. (Then again, most of it is written by biologists.)

Re:The "C" for some field?

[reve_etrange]

This is because Google's algorithm is poor, not because the language is named Julia.

Re:The "C" for some field?

[reve_etrange]

Before I get flamed: I don't think that Google's algorithm is worse than that of any particular competitor, or that semantic analysis is easy. The search algorithms we have just aren't that good.

Re:The "C" for some field?

[jedwidz]

Then again, most of it is written by biologists.

You mean 'evolved by biologists'. They aren't strong believers in intelligent design.

Re:The "C" for some field?

[Samantha Wright]

That joke cuts too close to home for me to outright laugh, but it's painfully true. Sometimes I don't think they can even plan paragraphs...

Re:The "C" for some field?

[cmarkn]

If only there were a way to pair a scientist and a programmer so that you had both skills sitting right there together writing the program, with one navigating the advanced math stuff while the other drove the good programming practices. Shirley, there must be somebody who's thought about how to do this. But perhaps it is just too extreme a practice to ever catch on.

Re:The "C" for some field?

[jedwidz]

... present company excluded, naturally.

Re:The "C" for some field?

[Samantha Wright]

...well, drawing a distinction. I'm technically a bioinformatician, and... actually no, that doesn't work. My classmates can't write for crap either. It's terrifying. Really.

Re:The "C" for some field?

[CSMoran]

I want to live on your planet. Every piece of numerical computing code I've ever seen is... well, discouraging. (Then again, most of it is written by biologists.)

My planet is quantum chemistry in the high-performance computing system and there are codes here that are maintainability nightmares as well. So I'd say it tends to be mutually exclusive, but doesn't have to be.

Other than occasionally using GAs, I don't have experience with computational biology, but I imagine biologists work a bit further from the metal, say in Python, R or Mathematica, whereas here there's almost always Fortran or C with assembly at the very bottom of everything. The stereotype is that biologists are not, on average, proficient programmers. Since you're a bioinformatitian, then, if the stereotype has some truth to it, I understand well what you mean.

Re:The "C" for some field?

[arth1]

You can't argue that C isn't readily or cheaply available -- it is.

It is readily available, yes. As long as you avoid VS and other IDEs that contaminate C with other languages and can't give you a "pure" C.

Cheaply? Not so much so. An experienced C programmer costs more than an experienced C++ or Java programmer these days, simply because C is no longer taught by default. (And no, knowing C++ or Objective C doesn't automatically make you experienced in C. Far from it.)
Plus the added cost of it being much harder to re-use and re-purpose code.

For Fortran, it's even harder to find good programmers. But if you work on e.g. meteorological data or other maths heavy stuff, it may still be the superior choice.

Not to say anything about assembly. There aren't a lot of application areas where every cycle counts any more, but they still exist. There are still no compilers who can match a really good hand coder, partially because a compiler can't know what's important (even profilers won't tell what's important, and are likely to assign a greater weight to "skies_all_clear" than the very infrequent "enemy_missile_detected"), and partially because a compiler won't come up with a new algorithm on the fly. Assembly buffs are also useful for debugging programs to find out why gcc or a black box library screwed up, so even if expensive, hiring at least one might be the superior choice.

In most cases, C++/java will get the job done, and that's what matters to the company who is in the business of making money, not necessarily superior products.

But that doesn't make C++/java superior, any more than a $18000 Kia is a superior car, or a $500 Dell PC is a superior PC - they both get the job done in the majority of cases, for cheap, but you have to stretch the definition of "superior" pretty far to apply that distinction to either. Superior to not getting the job done at all, granted.

Re:The "C" for some field?

[Raenex]

An experienced C programmer costs more than an experienced C++ or Java programmer these days, simply because C is no longer taught by default.

That statement is hard to verify. I looked and the best I could come up with is this, which shows that C programmers are actually cheaper. Maybe you can find some other numbers that back up your claim.

Of course, you might ask yourself why the market moved away from C, when it was initially neither cheaper or readily available to do so. The simple facts are that C is error-prone and low-level, and people have moved on to more productive languages.

Re:The "C" for some field?

[Samantha Wright]

Ah, "codes!" The great shibboleth of traditionally-bred scientific computing. :) Strangely, in four years of courses, I only heard the plural form uttered once in person.

Your language selection is pretty close—but it's MATLAB, not Mathematica that gets used. Mathematica just doesn't have the toolboxes for complex analyses on large datasets, which is pretty much what most of bioinformatics tends to be.

I think a significant part of the sad truth is that a lot of programmers that actually hail directly from biology are self-taught, or acquired their knowledge from reverse-engineering a mentor's work. This means that anyone in the field over the age of forty or so would have most likely learned to program on cheap, memory-constrained minicomputers (PDP-8s, and so on) that had a severe preference for terseness; possibly even BASIC. I've seen this first-hand; a couple of years ago I helped one of my physiology professors update his cache of VB3 demos to VB6 because his Windows 7 laptop wouldn't tolerate Win16 binaries. All of his algorithms came from a book that probably dated to 1979, and had been targeted at—lo and behold—OS/8 BASIC.

Still, that doesn't quite explain some of the WTFs that I've seen in more sophisticated code. One of my current mentors, who spends most of his time in Python—a younger professor—is characteristically a sociable, conscientious netizen who can effortlessly write good code, but the C++ his thesis supervisor wrote looks like linguine. (And I'm still trying to figure out how you introduce a bug that outputs unwanted buffer padding to a file.) I think a big part of the problem is that, unlike physicists such as yourself, biologists are used to perceiving mathematics as a black box that generates desirable results, rather than an end in itself; all the curriculum expects us to do is grasp the concepts behind what things like integrals and progressive component analysis do. We don't even cover complex numbers. I've complained to a few lecturers (and an undergraduate chair) about this general sort of shortcoming, and they were all too happy to point the blame at each other.

There was an article here a while ago about scientists viewing a program as an extension of themselves, rather than an external object, and I think the article must have meant to imply wet-lab scientists. Jedwiz's quip about it being evolved rather than designed is just so terrifyingly true it's hard to ignore.

Re:The "C" for some field?

[lsatenstein]

There is an old interpreted language that lost favor when Excel arrived on the scene.
That language had excellent statistical and matrix capabilities.

The language was invented by Dr Ken Ivorson and it is called APL.

It is truly a great answer for mixing matrix, linear algebra, and more.

Re:The "C" for some field?

[bmo]

I was poking around in your recent comments because I think you're smart, and I came across this:

This means that anyone in the field over the age of forty or so would have most likely learned to program on cheap, memory-constrained minicomputers (PDP-8s, and so on) that had a severe preference for terseness; possibly even BASIC.

I thought I'd give some personal perspective from a dirty old man who was once a 13 year old kid at a keyboard learning how to plot trig functions for a "downhill skiier" game (writing one of these was a right of passage, I believe).

Those of us over 40 cut our teeth on the Apple ][, Commie 64, TI 99/4a, Spectrums (Spectra!?), BBC computers across the pond, etc. IIRC, from his biography, Linus Torvalds learned how to program on his uncle's Vic20, which had a ridiculously small memory, something like 8KB or so. If it wasn't BASIC, it was Assembly (more likely than Pascal) or merely typing hex code in monitor mode on the Apple ][, for example, and no actual human-readable language at all. The preference for terseness is because of what we had to deal with. You either learned to write really, really tight code or it was simply not going to fit.

It was bitchin' when you could type PR#3 (mount the card in slot 3) on the Apple and get a whole 80 columns of text instead of 40.

If you have a prof, mentor, or colleague that writes code and he or she is over 40 and the code is full of single character nondescript variables, this is why.

So there you go.

--
BMO

Re:The "C" for some field?

[bmo]

I said "right of passage"

What the hell, bmo.

--
BMO

Re:The "C" for some field?

[Samantha Wright]

Don't worry, I know. :) I had the luxury of cutting my teeth predominantly on QBASIC, a decade and a half after its time in the sun was long passed (for reference, I'm only 23.) While certainly many young people who grew up to be computer scientists and professional programmers would have learned on 8-bit boxes, I was thinking about graduate students who had learned programming on the job in order to run biological analyses—and it seems they'd be more likely to have access to a mouldy departmental minicomputer than the family micro. Maybe my estimated age range was a bit low.

Re:Oblig. xkcd

[hcs_$reboot]

Why does the Oblig always misses the <a> tag? Even in Chrome, select + goto takes more time than a simple click.

Sage

[donaggie03]

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.

Not This Again

[eldavojohn]

You know, I bet that if you spent as much time learning new languages as you did bitching about duplication in Dart, Julia, $NEW_LANGUAGE then you'd have a pretty powerful array of tools to use in programming. From one of the authors of Machine Learning for Hackers' blog:

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.

Re:Not This Again

[gbjbaanb]

of course, if I spent as much time learning all the new languages that I am informed I should be learning, then I'd have no time left to actually use them for real work.

I guess, for some people, that is a result.

(or in other words, I think it's often better to write libraries for existing languages)

Re:Not This Again

[AchilleTalon]

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.

Re:Not This Again

[HiThere]

For me it looks ALMOST like the language I want. Unfortunately, the weaknesses render it a poor choice. E.g., I need a basic GUI capability. Julia would appear to require that I drop into C to achieve this.

OTOH, this *is* essentially an alpha release, not a beta. So I couldn't pick it anyway. But it *is* quite interesting. And it doesn't look as if it's solely for numerically intensive applications, though it may, indeed, be optimized for them.

Re:Not This Again

[Hatta]

Why does it matter if the core language has GUI facility? If you're writing in C, you're going to call out to a library for your GUI anyway. Why not call out to a library from Julia? That's how we do it in R anyway, there are packages to interface with GTK, QT, WX, TCL/TK, etc.

Re:Not This Again

[marcosdumay]

Well, you must release the language for somebody to write a GUI library for it. If the language becomes sucessfull, it will have plenty of native GUI libraries.

Re:Not This Again

[HiThere]

It matters because every time the (separate) gui library updates, the language gui is broken. It matters because calling external libraries is always flaky. In Python I've ended up going with tcl because of this. In some languages I've just given up.

If you're going to write something once and then forget about it, then it doesn't matter much that the library is separate. If it's going to keep being used, then it does. Breakage can be expensive. I suppose that it all depends upon your use case.

Version 3f670da0

[hey]

What is that a hash of the source code?

Re:Version 3f670da0

[ifrag]

What is that a hash of the source code?

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

Re:Version 3f670da0

[TheRaven64]

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.

Re:Version 3f670da0

[sourcerror]

It's not git specific, all distributed versioning systems use hashes for versions.

Re:Version 3f670da0

[TheRaven64]

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.

Re:Version 3f670da0

[BZ]

The problem, of course, is that the values of the counter in two clones of the same repo can be different, depending on exactly when they were cloned and when they pulled since then.... So the usability of the monotonic counter is pretty limited. And I say this as someone who spends a _lot_ of time with Mercurial.

FORTRAN?

[TWX]

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.

Re:FORTRAN?

[Hentes]

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

Re:FORTRAN?

[Anonymous Coward]

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:FORTRAN?

[Dr. Tom]

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

Re:FORTRAN?

[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.

Re:FORTRAN?

[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 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.

Re:FORTRAN?

[Lawrence_Bird]

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.

Re:FORTRAN?

[jgtg32a]

Doesn't modern FORTRAN have that?

Re:FORTRAN?

[Bill_the_Engineer]

Yes and is used extensively. There are even C libraries that include FORTRAN code to numerical work quickly.

Re:FORTRAN?

[Bill_the_Engineer]

I work with people who use FORTAN because it's not only tried and tested but also the fastest for numerical computing.

Re:FORTRAN?

[Zordak]

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.

Re:FORTRAN?

[redelm]

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.

Re:FORTRAN?

[TWX]

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 helpful. As opposed to throwing out the baby with the bathwater. In that sense, 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!"

Re:FORTRAN?

[jythie]

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 the same problems over and over as programmers slowly notice 'oh dear, we actually do need XYZ from the language we stopped using, ok, put that in too'.

Re:FORTRAN?

[rmstar]

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 think C++ is a point in case for why the second approach, the one you ridicule, would have been better. C++ is a hideous mess in many ways, and one of the big reasons is backwards compatibility with a language that simply wasn't prepared for Bjarne did to it. A clean start may have been better in so far as the language is concerned.

Re:FORTRAN?

[ahoffer0]

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

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.

Re:FORTRAN?

[gl4ss]

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?

[plopez]

Ummmm..... Fortran has supported free form format since ummmm..... 1993. All modern Fortran compilers I know of support both the old and the new formats. Cast off your old prejudices and learn what a modern programming language Fortran '08 really is.

BTW, I believe using the "FORTRAN" has been deprecated since the 70's. It is now "Fortran".

Re:FORTRAN?

[digitig]

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-level language to drop into for speed, but there is a limit to how far you can take a language by bolting new features on; eventually the underlying foundations just won't take the weight and you have to tear down and rebuild.

Re:FORTRAN?

[rgbatduke]

Oh Lordy, for some mod points. Of course then I'd have to decide, +1 for funny, +1 for informative, +1 for insightful...

I'll hold it down. Get your gun.

rgb

Re:FORTRAN?

[Medievalist]

and how is FORTRAN highly productive?

Well, we landed men on the moon with it, and safely returned them to earth.

Some of the FORTRAN code I wrote back then is still being used today.

Seems pretty productive to me.

Re:FORTRAN?

[MeanGene]

Hey - at least Fortran does not rely on whitespace!

Re:FORTRAN?

[HiThere]

Fortran has been extensively rebuilt. It's main problem is the usual one: You need to drop into C to use independent libraries. There are attempts to make it easier, but there are serious impedance matching problems.

Julia shares these same problems, worsened by the fact that it's still an alpha release with not much community support. OTOH, it does appear to make parallelism much easier than Fortran does, with not too much overhead.

Re:FORTRAN?

[deKernel]

Well, if you require all of those language features to implement your design, then I would think that Fortran is not the language for you. With that, don't be surprised that there are quite a few people that don't require all of those language features and can implement the design with Fortran.
Please don't think I am dogging you here, that is not the intent. Every language has trade-offs, I have found that I can can pretty much use any language in any capacity.

Re:FORTRAN?

[TWX]

I think that most state governments still use it for their budgeting too. That's a lot of very important usage.

Re:FORTRAN?

[mbkennel]

Most "modern computer languages" also have mediocre support for reliable and fast numerical computing.

The problem is that "modern computer langauges" are designed by PhD's in computer science who know what they learned in grad school, which is heavy on the "delegates? Anonymous functions? Closures? Reflection" axis of desiderata and pffs away questions of fast numerical support with "link to C"---mostly because something like that wouldn't be seen as New And Cool by tenure committees.

Uh, no---we want good quality, productive and high level language to write NEW algorithms, which must be fast, and make use of some data structures of moderate sophistication---and the speed can't suffer when we use capabilities beyond Fortran 77.

Re:FORTRAN?

[Tassach]

The problem is that "modern computer langauges" are designed by PhD's in computer science who know what they learned in grad school, which is heavy on the "delegates? Anonymous functions? Closures? Reflection" axis of desiderata and pffs away questions of fast numerical support with "link to C"---mostly because something like that wouldn't be seen as New And Cool by tenure committees.

Citation needed. Looking at the modern language landscape, what I see is are languages that were:
a) created by lone hackers looking to scratch a personal itch (EG: Perl, Ruby)
b) created internally by a corporation to solve an otherwise intractable engineering problem (EG: C, Erlang)
c) created by corporations looking to sell developer seats and/or create vendor lock-in (EG: Java, Visual *, *.net)

Languages designed primarily as academic exercises / thesis projects have historically had very small user bases outside of academia, with a few exceptions.

Anonymous functions, closures, reflection, etc are not esoteric Ivory Tower language features that are important because they're "cool" -- they're important because they're essential for efficient metaprogramming and higher order programming.

Re:FORTRAN?

[RightwingNutjob]

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 languages, and can generally be used for all parts of a project. The complaint that statistics is painful in MATLAB is a symptom of not knowing MATLAB. I haven't used R, but I'm willing to bet the complaint that R isn't good for linear algebra is about just as credible.

Speed for both of them is another issue altogether.

Re:FORTRAN?

[RightwingNutjob]

Modern my foot. Almost every language you've listed there was around in some form 20 years ago, and evolved from established engineering practices in software work. Further, calling C "modern" is a stretch. It's one notch above assembly (that's a complement), and doesn't have any of these pinko computer science concepts in it. C++ does, Java does, but just as the determined Real Programmer can write a FORTRAN program in any language, so can a determined engineer be skilled, fluent, and effective with C++, Java, .net, and whatever without ever using an anonymous function, delegate, or any thing else that Turing or von Neumann wouldn't be familiar with.

Re:FORTRAN?

[RightwingNutjob]

You can make a mess with any language.

You can make a royal mess with just C by undisciplined use of basic language features such as goto's and function pointers. Good C programmers don't make messes.

Similarly, you can make a royal mess with C++ by mixing references, pointers, malloc's, delete's, new's, goto's, and operator overloading. Good C++ programmers know not to make those messes by using natural barriers in the language to create barriers in their design patterns in which different styles of code to solve different types of subproblems don't mix and spaghettify with each other.

To put it bluntly, when one complains that a language is stupid, it is worth considering whether it's really the language that's stupid.

Re:FORTRAN?

[rmstar]

Good C++ programmers know not to make those messes by using natural barriers in the language to create barriers in their design patterns in which different styles of code to solve different types of subproblems don't mix and spaghettify with each other.

Good brainfuck programmers can make beautiful programs that are easy to mantain. That is not the point.

Having to know all the superfluous arcana you need to know to be a good C++ programmer is a huge burden. That's the reason why C++ should be avoided like the plague.

To put it bluntly, when one complains that a language is stupid, it is worth considering whether it's really the language that's stupid.

Well, yes, I agree. With C++ it is clear: it is a stupid language that empowers the stupid so that together they can make an epic mess. I'd rather have a language where that isn't so easy. Industry agrees, and that's why java is so big.

Re:FORTRAN?

[RightwingNutjob]

I'd rather have good programmers and an OK language than an idiot-proof language and a bunch of idiots just to make sure,

It's the packages stupid!

[Hatta]

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?

Re:It's the packages stupid!

[Hentes]

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. The only thing that has to be reimplemented is a wrapper if you want a friendly interface.

Re:It's the packages stupid!

[happy_place]

http://pdl.perl.org does lots of math and is still going strong...

Re:It's the packages stupid!

[danfromsb]

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.

Re:It's the packages stupid!

[Archibald Buttle]

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.

Show me the beard

[Anonymous Coward]

How can they expect me to commit to this new language unless I have seen what kind of facial hair they have. I want huge beards on their front page.

Numerical Python

[Dr. Tom]

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

Re:Numerical Python

[spike hay]

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.

Re:Numerical Python

[daid303]

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

Re:Numerical Python

[waives]

Two words: list comprehensions. Suck it matlab.

Re:Numerical Python

[plopez]

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.

Re:Numerical Python

[wfolta]

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.

Re:Numerical Python

[sourcerror]

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

Re:Numerical Python

[aisaac]

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.

Re:Numerical Python

[SwedishPenguin]

How optimized are the numerical operations in NumPy? Matrix operations and such seems to me to be pretty much the only part optimized about Matlab, but those are also quite fast and even does some pretty decent threading. Other than that (and the large library of stuff I want to use), Matlab is a horrible language in terms of speed, though the syntax for matrix operations is also quite nice. Even function calls are horribly slow. The only way to get decent performance out of Matlab is to use vector operations wherever possible.

Does Karpinski have a beard?

[alva_edison]

Beard Ref

Also is this named after the same Julia that worked with fractals? Julia Ref

Re:Does Karpinski have a beard?

[Baron von Leezard]

Karpinski does at the moment have a beard. – Karpinski

Evidence: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Julia

Re:Does Karpinski have a beard?

[PPH]

This doesn't explain COBOL.

Re:Does Karpinski have a beard?

[Baron von Leezard]

It is under active development.

I already dislike it

[GlobalEcho]

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.

Re:I already dislike it

[Thelasko]

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.

Re:I already dislike it

[Hatta]

Why can't MATLAB determine whether the arguments to the multiplication are scalars or matrices and just do the right thing? Isn't the multiplication of two 1x1 matrices the same as scalar multiplication anyway?

Re:I already dislike it

[Rhacman]

Yes, for the 1x1 case what you state is true and MATLAB will have no problem regardless of which operator you use. MATLAB will never yell at you for using the wrong version of the operator unless an actual operation is performed that doesn't make sense for the operator you specified. The only real issues arise when both versions of the operator can be computed and the developer chose the wrong one since it will silently produce an unintended result (it is valid to multiply two same-sized square matrices via element-wise or via matrix multiplication but likely with VERY different results). The complaint is regarding which operation * should specify. Since MATLAB was designed as a platform for matrix computation they choose for * to specify matrix multiplication.

Re:I already dislike it

[GlobalEcho]

Yes, for the 1x1 case what you state is true ...when both versions of the operator can be computed and the developer chose the wrong one since it will silently produce an unintended result...Since MATLAB was designed as a platform for matrix computation they choose for * to specify matrix multiplication.

Good explanation. To amplify this point with respect to Julia, if the Julia developers really intend it to be merely a matrix computation platform then they chose the right syntax.

Based on the linked materials, though, it seems they are really aiming for the general numerical computing crowd. If so, their choice of syntax is a grave mistake. Matlab may be stuck with it for historical reasons, but I have no desire to go back to finding bugs whose presence is inferred by noticing a single pixel on my monitor or, worse, the lack of it.

Tangentially

[dark12222000]

Working in a tangential field, I've always felt one of the major choke points for doing numerical work in C or Java is the speed of development for programmers who don't strongly specialize in these languages already. While I understand this may be a niche, I'm curious (and perhaps someone can inform me) of the ease of development in Julia, as well as the speed of development. While this seems to be a main concern according to the summary, is this actually achieved, and if so, how?

Matlab and R give you a lot of power with a relatively small and simple command set. While they are both specialized to particular branches of mathematics and have less then optimal performance, they allow most anyone with mediocre programming knowledge to build sufficient programs.

Re:Tangentially

[Baron von Leezard]

There's a few points:

1. Julia is entirely dynamic, so there's no need to think about compile time versus run time, simplifying the mental model (but the performance is like that of compiled languages). It's as easy as Python or Matlab in that respect, but much faster.
2. There are just a few powerful language features (e.g. ubiquitous, fast multiple dispatch, supported with an expressive type system), rather than a lot of features that interact in complicated ways.
3. Good for general programming stuff: working with strings, calling external programs and other things that are generally pretty awkward in R and Matlab (one of the reasons why NumPy is gaining popularity).

In general, the motivation (expressed in a previous Julia blog post) is to have something that's easy to use and learn, but fast and powerful (you *can* go deep if you want to), and designed expressly for numerical work —which means, among other things, that it has to be able to store large arrays of numeric values in-line and call libraries like LAPACK on them.

Stefan Karpinski

Why?

[Anonymous Coward]

Matlab is not a programming language, per se, but a numerical computing environment heavily geared towards linear algebra and its applications. You use the language to write scripts and interact with it. Having said that, I don't get the purpose behind this language and what it has to do with C. You don't "choose" Matlab over C. That makes no sense. The basic work flow is that one uses Matlab to simulate an algorithm/process. If it needs to be turned into a real product or something, then you can do it yourself in C or use Simulink, an accompanying package, to help. Does Julia or Matlab or R run on a signal processor? That is silly. The people behind Julia are obviously missing some basics. Maybe they should actually ask someone how Matlab is used in the real world.

Re:Why?

[Entrope]

Once certainly does choose MATLAB over C -- one chooses the MATLAB language over C because the former makes it much easier to represent many mathematical operations; one chooses the MATLAB libraries and execution environment because they are richer than C in mathematics building blocks. When a particular numerical analysis needs to be performed at most a few times, development time becomes a major factor in the cost, which is why people would prefer MATLAB over C -- but the MATLAB execution time might be so long that alternatives become interesting.

(I suspect that Julia and R do not have code generation for signal processors, but Mathworks and its partner companies will gladly sell you tools that will convert a subset of MATLAB code to C or an HDL to run on an embedded system or FPGA. They will even give away free stories about how awesome those tools are, while glossing over their limitations, but hey -- they are sales pitches..)

Re:Why?

[Baron von Leezard]

As I mentioned in the interview, we're working on a compiler, at which point you would even be able to use compiled Julia code in embedded systems. So you get a nice productive, interactive development environment, then you invoke the static compiler and presto! you have a compiled .so files that you can just call from C. That eliminates the need to prototype in one language and then re-write everything in another language when you want to actually deploy it. I've done that before and it's deeply annoying, time-consuming, and hard to get right (it's generally harder to write correct C code than correct Matlab code). I've also deployed Matlab using their compiler. That's workable if you want to avoid re-writing your prototype, but it's also pretty annoying.

Stefan Karpinski

Re:Why?

[Baron von Leezard]

Yeah, at some point if you need to put code on something like an embedded processor or DSP you just got to get down and dirty with C code and probably some ASM. But there's still some room in the middle for less pain with good performance :-)

Re:Why?

[A Nun Must Cow Herd]

This is fantastic. I think Julia has the right focus to be better for many purposes than MATLAB and C++, and if a compiler is coming it's even better. I'm familiar with MATLAB, Mathematica, Octave, C and C++, and the Julia language looks very easy to learn and use. I also applaud your choice of the MIT license - I hope this permissive license encourages widespread use and innovation - both for free and commercial software. Thank you!

Fortress

[l00sr]

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 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?

Re:Fortress

[arth1]

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 them obsolete the car, just as new programming languages seldom obsolete existing ones.

Re:Fortress

[dougmc]

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.

Re:Fortress

[plopez]

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

Re:Fortress

[l00sr]

The most advanced feature I see there is OO. If you think that OO is the pinnacle of modern language design, I highly encourage you to try out ML or Haskell and see the light.

Re:Fortress

[dougmc]

The most advanced feature I see there is OO

OK, but the simple fact that OO was added, all by itself, is sufficient to make your statement of "it entirely misses out of 50+ years of research and innovation in programming languages" to be completely false. And of course it's only one of many features added in the last 50+ years.

If you think that OO is the pinnacle of modern language design

An attempt at a strawman?

I didn't say these features were awesome or that OO was the "pinnacle of modern language design" (I didn't bring up OO at all -- it's just one of several features added to Fortran over the decades.)

I just pointed out that your statement was completely false.

APL?

[crow]

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:APL?

[michael_cain]

What was Dijkstra's quote? "APL is a mistake, carried through to perfection." At one point, though, consider what IBM's implementation gave you that simply wasn't available elsewhere (other than Lisp, of course): stack traces, interactive symbolic debugging, self-modifying code, etc. I will never forget the numerical analysis programming assignment that was supposed to take three weeks, and writing it in one night using APL.

I admit, I still use a toy APL interpreter as a desktop calculator, that uses a bizarre mapping of ASCII characters to APL symbols so you can type things on a regular keyboard. The source code for the interpreter -- in hideously old-school C -- traces back to Ken Thompson at Bell Labs, with lots of bits added later at Berkeley, Yale, and especially Purdue.

and the irony...

[l00sr]

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

Re:and the irony...

[gazuga]

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

Statistics in Matlab is frustrating?

[codeAlDente]

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)?

Yet another language

[Compaqt]

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?

Re:Yet another language

[SQL Error]

It even looks vaguely like JavaScript, so why bother?

Because JavaScript.

Re:Yet another language

[Compaqt]

>Because JavaScript.

Was that supposed to be a macro to "insert standard Slashdot anti-Javascript text here"?

Anyways- Why Javascript:
1. It's easy to learn
2. It's based on the same syntax that C/C++/Java and some others are based on (PHP, too, kinda). So most people already know it, in a way.
3. It's everywhere, which also means your local high-schooler (including your interns and graduate TAs) probably already know it.
4. It benchmarks near Julia

Oh, and by, the way, I turn Javascript off for most of my browsing, since I just don't need it. And so I'm an anti-FX snob in that way, but that doesn't mean I'm going to irrationally be against the language itself.

Re:Yet another language

[Baron von Leezard]

That's a fair question, and one I asked myself after writing the benchmark code for JavaScript and seeing just how incredibly fast the V8 engine is. Should we be doing numerical computing in JavaScript? The biggest problem that I can see is that JavaScript doesn't have a good story for calling external C/Fortran libraries. Some sort of FFI could be implemented, but there are deeper issues —especially the paucity if numerical types in JavaScript. JavaScript doesn't even have integers —every number is a double. So how can you distinguish between an array of integers versus an array of doubles that happen to have integer values? Can the compiler be smart enough to know that it can store those numerical arrays inline in a format that can be passed to LAPACK? To do numerical computing, you really need more control over memory layout, at the very least for the sake of calling external libraries.

Stefan Karpinski

Re:Yet another language

[BZ]

Stefan, you know about http://www.khronos.org/registry/typedarray/specs/latest/ right?

Re:Yet another language

[Baron von Leezard]

Yeah, I think that was mentioned in Luke Hoban's talk on ECMAScript at Lang.NEXT (if not, I saw it elsewhere that I can't recall). That would certainly help and even make calling LAPACK possible in JavaScript, but I still think it wouldn't be much fun. It would be pretty cool though :-)

Re:Yet another language

[BZ]

For what it's worth, both Spidermonkey and V8 support those, and support is coming in other browsers.... Might still be fun for something like LAPACK, of course.

Re:Yet another language

[Compaqt]

OK, fair enough, thanks.

I'm sure the language will be useful for many.

Re:Yet another language

[kyrsjo]

Exactly - I'm a physicist doing quite a bit of number crunching, and know the languages you mention there fairly well (except maybe Fortran). And then you can add C++, and the various technologies used to make things work, like MPI, batch systems, and more. And, you know, the actual math and physics...

JavaScript and PHP? Never touched those. Learning some early version of HTML (ca. 1998) in grade school was the closest I got - but hey, you could make games in that too (using a LOT of static pages)!

Re:Oblig. xkcd

[camperdave]

Exactly! Slashdot wastes enough of my time. Must I be forced to highlight, right click, and select an option from a menu? It's not like typing behind is a lot of work. See: http://xkcd.com/927/

lush (Lisp Universal SHell)

[AchilleTalon]

Anyone using or used lush here can compare?

Re:lush (Lisp Universal SHell)

[zmughal]

I've looked at Lush and I like the fact you can embed C code straight in the Lisp. And it's fast. Though it concentrates on the numerical computing, rather than symbolic computing. It could do with more clean and easily installable library bindings, which is where MATLAB and Octave shine in terms of the breadth of functions available.

APL? No thanks.

[Viol8]

"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.

Re:APL? No thanks.

[arth1]

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.

Re:APL? No thanks.

[crow]

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.

Pretty

[AdamHaun]

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.

Re:Pretty

[SQL Error]

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....

Existing Codebase

[wed128]

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.

Re:Existing Codebase

[plopez]

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.

Re:Existing Codebase

[Baron von Leezard]

You can't do this just yet, but we're working on it. Should be possible in the near future. At some point further into the future, you'll be able to compile Julia code into a .so file, load it from C code and just call it as though it were written in C —except that the person writing the code gets the benefits of a high-level numerical language.

Stefan Karpinski

Re:Existing Codebase

[wed128]

That's exactly what I'm looking for! I look forward to seeing your work...this looks very interesting!

Fortran anyone?

[treerex]

C : GeneralPurposeProgramming :: Fortran : Numerical Computing The title of the post is off, or misleading, or ignorant.

Re:Fortran anyone?

[Baron von Leezard]

I didn't write the title the interview article. It's definitely inaccurate since C is already the C of scientific computing.

Stefan Karpinski

Re:Fortran anyone?

[treerex]

I did not mean to infer that you, or any of the creators of Julia, were making the comparison, and I hope it was taken as such.

MIT License, not GPL

[vAltyR]

The core Julia implementation uses the MIT License, not the GPL. See the license information here.

Re:MIT License, not GPL

[vAltyR]

Whoops. Should have read the next sentence on the front page of julialang.org:

The core of the Julia implementation is licensed under the MIT license. Various libraries used by the Julia environment include their own licenses such as the GPL, LGPL, and BSD (therefore the environment, which consists of the language, user interfaces, and libraries, is under the GPL).

Re:Mutually exclusive goals

[TheLink]

In other words, at the very least, the dynamic languages will have to do a table lookup and then call the function, as opposed to just calling the function.

Maybe someone should have a word with Intel/AMD. After all they seem to be running out of ideas on what to do with all those transistors.

Re:I "C" what they did there...

[kfsone]

The "CPP" file, for those interested: https://github.com/JuliaLang/julia/blob/master/test/perf/perf.cpp

Re:Oblig. xkcd

[Noughmad]

Why does the Oblig always misses the <a> tag? Even in Chrome, select + goto takes more time than a simple click.

Because if don't know the xkcd strips by number, there's a card you might be expected to hand in as you leave.

Re:Mutually exclusive goals

[sourcerror]

In other words, at the very least, the dynamic languages will have to do a table lookup and then call the function, as opposed to just calling the function.

.Net and the JVM also do that.

surely when talking about speed they mean

[mjwalshe]

"(Did we mention it should be as fast as FORTRAN?)"

Not fast at all

[loufoque]

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:Not fast at all

[Baron von Leezard]

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.

Re:Not fast at all

[IncandescentFlame]

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.

Mod parent down. This is completely wrong. You clearly haven't looked at Fortran for about 30 years. Fortran has had modularity since Fortran 90, and modern Fortran has object orientation, inheritance and polymorphism. In terms of numerical performance the Fortran compiler will still leave the C++ compiler laying on the ground, weeping.

So what exactly is the high-level programming feature that C++ has that Fortran doesn't? Is the write-once, read-never quality that a lot of C++ code has, because I am happy to live without that particular "feature".

Re:Not fast at all

[loufoque]

Fortran has had modularity since Fortran 90, and modern Fortran has object orientation, inheritance and polymorphism.

First, no one is using these.
Second, they can't compare with what other languages offer and they make no sense, which is why no one is using these.

In terms of numerical performance the Fortran compiler will still leave the C++ compiler laying on the ground, weeping.

Where did I say otherwise? I talked about *control* of performance, not performance that is obtained with default, automatic and built-in processes.

So what exactly is the high-level programming feature that C++ has that Fortran doesn't?

FORTRAN is not really low-level, but it's not really high-level either. For example, unlike a language like MATLAB, you still write loop nests, and you rely on the compiler to detect that some loop nests can be parallelized and to parallelize them (and even if it can do a bit better than in C, the compiler still can't guess everything for you). The highest level languages or library frameworks allow you to define several components that are then combined to parallelize a given computation element in a given fashion. FORTRAN typically lacks both the high-level (generic combination) and the low-level (explicit memory and parallelization management) facilities to achieve such things. It is a simple, single-purpose, non-extensible language, where you need to keep code simple and rely on compiler optimization magic.

C++, on top of very low-level, has very high-level constructs. For example it has facilities (templates, overloading, specialization) that allow to define an domain-specific language embedded within the language itself, that can be analyzed and for which C++ code can be generated as the C++ code is compiled.
Generative and generic programming techniques enable no-cost definition of high-level constructs with very rich semantics to which you can attach generic primitives to build the patterns and algorithmic skeletons which can be used to generate many applications within a specific domain, domain for which it is humanly known how optimization or parallelization should be done, allowing you to engineer it into the system.

The fact that the language itself allows the compiler to be programmed enables to enrich the language with more knowledge of a particular domain and how to best deal with it. General-purpose approaches only go so far; domain-specific libraries is where most of the value is.
Obviously, this is only really useful if you have value to add on top of the generic approaches that your compiler has built-in, or if you wish to have control over how your application makes use of the hardware.

Re:I "C" what they did there...

[Baron von Leezard]

The C/C++ benchmarks are intentionally written in C; the only reason that's it's a C++ files instead of C is so that we can use C++'s complex template in the Mandelbrot benchmark. Otherwise the whole thing would just be done in C. The clock_now function is only used to time other code, so its performance is irrelevant.

Stefan Karpinski

Why don't scientists use functional languages?

[mbkennel]

The physical world, and the hardware in the computer, is stateful, not-stateless. There is a finite amount of storage, which can be overwritten.

The idiomatic programming model for functional language isn't like this.

In a functional language to ensure you get fast code, you have to both have a mental model of the program, and a much more complex mental model of the transformations that your functional compiler might (or might not!) apply. This is often exceptionally hard.

A human, like a numerical programmer, has some clever knowledge about how best to order and arrange things to map to an efficient implementation in a stateful world.

Take, for example, a production-level SVD algorithm. You could probably express a SVD method in a functional way. Would it be fast, and have low memory usage, no needless temporaries? (in high performance computing these always go together) Well maybe but you'd have to really massage things in light of a particular implementation's optimizer & quirks. That isn't something scientists have the desire to do.

In practice, the capability of imperative, but data-parallel languages best map to their user's knowledge and capabilities and existing technology for quality execution.

Re:Mutually exclusive goals

[cnettel]

In other words, at the very least, the dynamic languages will have to do a table lookup and then call the function, as opposed to just calling the function.

.Net and the JVM also do that.

Not true. In Java, methods are virtual by default, so there is some truth there. However, the JIT in the JVM will frequently be able to infer the true actual type and inline or at least do away with the vtable lookup. In .Net, the default is non-virtual methods, but even when methods are virtual, the same facts about type inference hold. In fact, these are reasons for why rather OOP-heavy designs might perform faster in .Net/Java than in C++ (unless you compile your C++ with profile-guided optimizations) - so many possible inferences and optimizations are only possible with the runtime binding information.

Re:Fortran.

[drkstr1]

Why don't you tell him yourself. He is here, posting comments. What great achievements have you made to call this person an idiot?

Julia Language ~ JULIAN ASSANGE

[Phoe6]

I do not know how I read Julia Language as Julian Assange and thought why he was assiciated with C for numerical computing. I had to read the title again. Doh!

Re:Missing Plotting Tools

[hcpxvi]

But the biggest pluses of Matlab is being able to plot your results, and work interactively from the command line
This. Precisely this. If Julia can reasonably rapidly acquire plotting capabilities that approach those of R (and hence are much better than those of MATLAB) then it may have some traction. If it remains the case that you have to dump your results out of Julia and use another tool to plot them, then you are better off using R/MATLAB/Octave/IDL/SciLab/Yorick for everything except the most number-crunchingly intense tasks. And you would probably do _those_ in a traditional compiled language anyway.