Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Julia Language Seeks To Be the C For Numerical Computing

Unknown Lamer posted more than 2 years ago | from the two-parts-fortran-one-part-lisp dept.

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

cancel ×

204 comments

The "C" for some field? (2, Funny)

Anonymous Coward | more than 2 years ago | (#39722833)

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? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#39722879)

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

As well as maintainability, readability, etc.

Re:The "C" for some field? (3, Insightful)

BenoitRen (998927) | more than 2 years ago | (#39722979)

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

Anonymous Coward | more than 2 years ago | (#39723065)

As well as maintainability, readability, etc.

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

Hehehehe you're funny. And so cutesy too! Tee hee! Your mommy must be so proud! Lolz! Just lemme pinch your widdle cheeks... Ok that's degrading enough. Not hamstringing the programmer with a shitty language definitely makes it easier for him to produce code that is maintainable, readable, etc.

Yes some programmers can produce epically beautiful code with the shittiest of languages. Just like Chuck Norris can believe it's not butter. But eh, let's not fixate on edge cases. You can surely see the correlation between taking a decent programmer and not giving him a shit language and seeing better code, right?

Re:The "C" for some field? (1)

StikyPad (445176) | more than 2 years ago | (#39723985)

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

Re:The "C" for some field? (1, Funny)

Samantha Wright (1324923) | more than 2 years ago | (#39724249)

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? (4, Insightful)

Lunix Nutcase (1092239) | more than 2 years ago | (#39723077)

If you aren't writing readable and maintainable code in C that's the programmer's fault. You aren't forced to use obscure abbreviations, bizarre inline hacks, etc. There is plenty of readable and well-maintained code that has been running non-stop longer than your modern langauges have existed.

Re:The "C" for some field? (1)

jythie (914043) | more than 2 years ago | (#39723607)

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? (3, Insightful)

Vegemeister (1259976) | more than 2 years ago | (#39724005)

The problem with C++ is that it has too many features, and too many ways to do the same thing. You can write complex application programs in C++ while only knowing a small subset of the language. The problem ocurs when someone comes along to maintain your code and knows a completely different subset.

Re:The "C" for some field? (5, Insightful)

swan5566 (1771176) | more than 2 years ago | (#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.

Re:The "C" for some field? (-1)

Anonymous Coward | more than 2 years ago | (#39722983)

Never seen a successful language named after a person. Probably never will. This "julia" is doomed to fail. DOOMED!!

Was this Julia a real person? Was she a fat chick? That's at least two strikes right there.

Like all fat chicks she has terrible self-esteem issues. Like all fat chicks she doesn't want to resolve those in the simple and obvious way: by losing the fucking weight. No, any moron can understand that you lose weight by eating fewer calories than you burn, and because any idiot can understand it, that is why it would all be too simple. For women in particular doing anything the simple way is sacrilige and not nearly expensive enough. Besides losing weight means she might run out of greasy comfort food that way. She might even have to DEAL WITH HER EMOTIONS like an adult person. It's either that or migrate from comfort food to comfort drugs.

Anyway, gentleman, all fatties are emotional trainwrecks trying desperately to appear mentally healthy, normal, sane, and equal to people who respect themselves enough to know when to put the fork down. Of course, all of these things are false. Fat chicks: what a waste of (what could have been) a perfectly good vagina. Yes they will do whatever you want because they are as desperate for male attention as they are desperate for food. They are still useless in every way. Fellas, don't bang fat chicks, don't date fat chicks, don't even talk to fat chicks. It is better and more dignified to stay home and jack off. As a breed they need to go the way of the dinosaur. If the blacks can just stop knocking them up (every disgusting whale of a fattie has at least one half-black kid) we'd make some progress!

Re:The "C" for some field? (3, Informative)

arth1 (260657) | more than 2 years ago | (#39723317)

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? (3, Interesting)

jythie (914043) | more than 2 years ago | (#39723619)

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

plopez (54068) | more than 2 years ago | (#39723913)

Like C#?

Re:The "C" for some field? (0)

Anonymous Coward | more than 2 years ago | (#39723989)

The original post was meant to be facetious and ended up just being obnoxious. But there is a kernel of truth about languages named after people being annoying-- it makes it harder to Google and get reasonable results. My immediate question was, "This looks interesting-- Is there an Eclipse plug-in?" Go ahead, try it. Look at the first page of results for:

Julia Eclipse plugin

I'll even help and tell you to throw in a "-Twilight" to help filter out a bunch of recent pop culture crap that contaminates the results.

Re:The "C" for some field? (1)

Surt (22457) | more than 2 years ago | (#39723381)

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

arth1 (260657) | more than 2 years ago | (#39723983)

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

claytongulick (725397) | more than 2 years ago | (#39724141)

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

StikyPad (445176) | more than 2 years ago | (#39724161)

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.

Oblig. xkcd (-1)

Anonymous Coward | more than 2 years ago | (#39722855)

http://xkcd.com/927/

Re:Oblig. xkcd (1)

hcs_$reboot (1536101) | more than 2 years ago | (#39722905)

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

Re:Oblig. xkcd (1)

camperdave (969942) | more than 2 years ago | (#39723367)

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 <url: in front and > behind is a lot of work. See: http://xkcd.com/927/ [xkcd.com]

Re:Oblig. xkcd (0)

Anonymous Coward | more than 2 years ago | (#39724229)

I couldn't find a reference for formatting comments on Slashdot after an initial search.

Not This Again (3, Informative)

eldavojohn (898314) | more than 2 years ago | (#39722941)

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 [r-bloggers.com] :

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 (2)

gbjbaanb (229885) | more than 2 years ago | (#39723039)

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 (3, Insightful)

AchilleTalon (540925) | more than 2 years ago | (#39723441)

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.

Sage (5, Informative)

donaggie03 (769758) | more than 2 years ago | (#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.

lush (Lisp Universal SHell) (1)

AchilleTalon (540925) | more than 2 years ago | (#39723505)

Anyone using or used lush [sourceforge.net] here can compare?

Version 3f670da0 (1)

hey (83763) | more than 2 years ago | (#39722949)

What is that a hash of the source code?

Re:Version 3f670da0 (4, Funny)

ifrag (984323) | more than 2 years ago | (#39723097)

What is that a hash of the source code?

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

Re:Version 3f670da0 (1)

TheRaven64 (641858) | more than 2 years ago | (#39723911)

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.

FORTRAN? (5, Interesting)

TWX (665546) | more than 2 years ago | (#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.

Re:FORTRAN? (-1)

Anonymous Coward | more than 2 years ago | (#39722981)

go back to the 70's FORTRANfag

Re:FORTRAN? (1)

Hentes (2461350) | more than 2 years ago | (#39723017)

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

Re:FORTRAN? (1)

jgtg32a (1173373) | more than 2 years ago | (#39723147)

Doesn't modern FORTRAN have that?

Re:FORTRAN? (3, Informative)

Bill_the_Engineer (772575) | more than 2 years ago | (#39723257)

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

Re:FORTRAN? (4, Informative)

gl4ss (559668) | more than 2 years ago | (#39724081)

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? (5, Interesting)

Anonymous Coward | more than 2 years ago | (#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:FORTRAN? (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39723101)

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

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

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

Re:FORTRAN? (2)

Bill_the_Engineer (772575) | more than 2 years ago | (#39723325)

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

Re:FORTRAN? (-1, Flamebait)

PvtVoid (1252388) | more than 2 years ago | (#39723859)

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.

c Any language that still relies on line formatting conventions left over from punch cards
c should be taken out back and shot.

Re:FORTRAN? (4, Informative)

plopez (54068) | more than 2 years ago | (#39724093)

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

rgbatduke (1231380) | more than 2 years ago | (#39724359)

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? (4, Interesting)

ahoffer0 (1372847) | more than 2 years ago | (#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.

Re:FORTRAN? (1)

digitig (1056110) | more than 2 years ago | (#39724327)

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

Anonymous Coward | more than 2 years ago | (#39723061)

and how is FORTRAN highly productive?

Re:FORTRAN? (1)

Dr. Tom (23206) | more than 2 years ago | (#39723063)

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

Re:FORTRAN? (1)

TWX (665546) | more than 2 years ago | (#39723661)

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

rmstar (114746) | more than 2 years ago | (#39723869)

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? (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39723083)

From wikipedia: "FORTRAN is a general-purpose, procedural, imperative programming language that is especially suited to numeric computation and scientific computing."

Sounds to me like unless there's a particular weakness in FORTRAN that doesn't lend itself to workarounds or repair in newer versions of the language, there's already a numeric computation and scientific programming language that's well documented, mature, and widely distributed.

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

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

Re:FORTRAN? (1)

Zordak (123132) | more than 2 years ago | (#39723363)

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

Lawrence_Bird (67278) | more than 2 years ago | (#39723121)

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 (1, Interesting)

l00sr (266426) | more than 2 years ago | (#39723143)

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?

and the irony... (1)

l00sr (266426) | more than 2 years ago | (#39723189)

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... (1)

gazuga (128955) | more than 2 years ago | (#39723285)

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

Re:and the irony... (0)

Anonymous Coward | more than 2 years ago | (#39723571)

Offtopic, I know, but was there ever a more manly name than 'Guy Steele'?

I can't think of a lot of names more effeminate than Guy, with its original French pronunciation. "Steele" too is a sissified "steel", probably used by people who run a cute shoppe.

Re:Fortress (1)

arth1 (260657) | more than 2 years ago | (#39723515)

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 (4, Informative)

dougmc (70836) | more than 2 years ago | (#39723529)

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.

Re:Fortress (1)

plopez (54068) | more than 2 years ago | (#39724121)

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

APL? (3, Insightful)

crow (16139) | more than 2 years ago | (#39723169)

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.

APL? No thanks. (1)

Viol8 (599362) | more than 2 years ago | (#39723547)

"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. (1)

arth1 (260657) | more than 2 years ago | (#39723707)

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. (1)

crow (16139) | more than 2 years ago | (#39724315)

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.

Re:FORTRAN? (1)

redelm (54142) | more than 2 years ago | (#39723655)

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

jythie (914043) | more than 2 years ago | (#39723691)

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

seems a dream come true (0)

Anonymous Coward | more than 2 years ago | (#39722977)

As a biologist that works with R daily for the last 12 years (I think the first R version I used was 0.65 and used S-Plus before that), this seems a dream come true. I'm fed up with using unpractical and ugly languages such as C and Java whenever R is too slow for the job, which in my case is quite frequently.

It's the packages stupid! (4, Interesting)

Hatta (162192) | more than 2 years ago | (#39723015)

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! (1)

Hentes (2461350) | more than 2 years ago | (#39723267)

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.

Re:It's the packages stupid! (1)

happy_place (632005) | more than 2 years ago | (#39723295)

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

Re:It's the packages stupid! (3, Insightful)

danfromsb (965115) | more than 2 years ago | (#39723965)

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

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

Show me the beard (1)

Anonymous Coward | more than 2 years ago | (#39723033)

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 (5, Informative)

Dr. Tom (23206) | more than 2 years ago | (#39723045)

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 (2)

spike hay (534165) | more than 2 years ago | (#39723139)

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 (2)

waives (1257650) | more than 2 years ago | (#39723355)

Two words: list comprehensions. Suck it matlab.

Re:Numerical Python (1)

plopez (54068) | more than 2 years ago | (#39724223)

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 (1)

daid303 (843777) | more than 2 years ago | (#39723261)

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

Re:Numerical Python (0)

Anonymous Coward | more than 2 years ago | (#39723993)

For numerical codes, Python can be 100x (and in some cases I have personally encountered 1000x) slower than C. Not saying anything against PyPy, but a speedup of 4x to 5x is not really relevant.

Does Karpinski have a beard? (1)

alva_edison (630431) | more than 2 years ago | (#39723075)

Beard Ref [khason.net]

Also is this named after the same Julia that worked with fractals? Julia Ref [wikipedia.org]

Re:Does Karpinski have a beard? (1)

PPH (736903) | more than 2 years ago | (#39724137)

This doesn't explain COBOL.

I already dislike it (2)

GlobalEcho (26240) | more than 2 years ago | (#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.

Tangentially (1)

dark12222000 (1076451) | more than 2 years ago | (#39723115)

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.

Why? (1)

Anonymous Coward | more than 2 years ago | (#39723125)

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

Entrope (68843) | more than 2 years ago | (#39723243)

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

Anonymous Coward | more than 2 years ago | (#39723899)

You don't "choose" Matlab over C. That makes no sense.

Plenty of people do exactly that. From what I've seen, typical reasons include ease of prototyping, a syntax that's closer to maths notation, and the easy built-in charting/plotting.

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.

Alternatively, you use the MATLAB Compiler to generate a distributable package that runs your m-files or p-files on the redistributable MATLAB Component Runtime. Their "compiler" (a bit of a misnomer for at least the last dozen versions) is very pricey though, plus you have to buy it again for every target platform, and it doesn't support all the add-on packages. OTOH, in at least one case (the fuzzy analysis add-on - I forget its proper name), compiler support for the package itself should be irrelevant because the package can generate portable C code. And yes, people use MATLAB this way in the real world.

- T

Statistics in Matlab is frustrating? (1)

codeAlDente (1643257) | more than 2 years ago | (#39723221)

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 (1)

Compaqt (1758360) | more than 2 years ago | (#39723331)

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 (1)

SQL Error (16383) | more than 2 years ago | (#39723439)

It even looks vaguely like JavaScript, so why bother?

Because JavaScript.

Fortran. (0)

Anonymous Coward | more than 2 years ago | (#39723477)

Someone, tell the idiot which created "julia", about fortrant. We've been using it for decades, for "Number Crunching".

Pretty (1)

AdamHaun (43173) | more than 2 years ago | (#39723551)

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 (1)

SQL Error (16383) | more than 2 years ago | (#39723695)

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 (1)

wed128 (722152) | more than 2 years ago | (#39723735)

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 (1)

plopez (54068) | more than 2 years ago | (#39724287)

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.

Fortran anyone? (1)

treerex (743007) | more than 2 years ago | (#39723737)

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

Mutually exclusive goals (0)

Anonymous Coward | more than 2 years ago | (#39723975)

AFAIK Ruby will always be slower than C or C++ because you have to be able to dynamicly modify classes. However, if you don't dynamicly modify any classes in your program than it seems like the vtable can get pulled into cache and you'll be OK. The real problem is that you have to call all functions through a vtable (or some equivalent) in the first place. Plain old C (or C++ without any virtual functions which is kind of boring) doesn't have this problem.

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.

If the language gives you the ability to mark up functions with some kind of optimization keyword (like C's restrict and const) then maybe they'll have something. Of course, what kind of weird runtime problems might they have with a dynamic language where *some* of the functions are nailed down and others are all loosy-goosy?

Re:Mutually exclusive goals (1)

TheLink (130905) | more than 2 years ago | (#39724335)

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.

MIT License, not GPL (1)

vAltyR (1783466) | more than 2 years ago | (#39724071)

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

Re:MIT License, not GPL (0)

Anonymous Coward | more than 2 years ago | (#39724217)

damn it. why wont these people understand that my freedom to limit your ability to not distribute
any changes you might make makes it impossible for me to use your system!

Re:MIT License, not GPL (1)

vAltyR (1783466) | more than 2 years ago | (#39724297)

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

Not functional. Epic fail. (-1, Flamebait)

melted (227442) | more than 2 years ago | (#39724341)

Not functional. Epic fail. Why (in the second decade of the 21st century!) would anyone want a fully imperative language for this? It's been done already, numerous times.

Instead, just take Scala and idiomatically port packages to it instead.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...