Julia Language Seeks To Be the C For Numerical Computing 204
concealment writes in with an interview with a creator of the (fairly) new language Julia designed for number crunching. Quoting Infoworld: "InfoWorld: When you say technical computing, to what type of applications are you specifically referring? Karpinski: It's a broad category, but it's pretty much anything that involves a lot of number-crunching. In my own background, I've done a lot of linear algebra but a fair amount of statistics as well. The tool of choice for linear algebra tends to be Matlab. The tool of choice for statistics tends to be R, and I've used both of those a great deal. But they're not really interchangeable. If you want to do statistics in Matlab, it's frustrating. If you want to do linear algebra in R, it's frustrating. InfoWorld: So you developed Julia with the intent to make it easier to build technical applications? Karpinski: Yes. The idea is that it should be extremely high productivity. To that end, it's a dynamic language, so it's relatively easy to program, and it's got a very simple programming model. But it has extremely high performance, which cuts out [the need for] a third language [C], which is often [used] to get performance in any of these other languages. I should also mention NumPy, which is a contender for these areas. For Matlab, R, and NumPy, for all of these options, you need to at some point drop down into C to get performance. One of our goals explicitly is to have sufficiently good performance in Julia that you'd never have to drop down into C."
The language implementation is licensed under the GPL. Lambda the Ultimate has a bit of commentary on the language, and an R programmer gives his two cents on the language.
The "C" for some field? (Score:2, Funny)
You mean, ignored by almost every developer in the field in lieu of more "business-friendly" languages that add bloat and inefficiency?
Re: (Score:2, Insightful)
You mean, ignored by almost every developer in the field in lieu of more "business-friendly" languages that add bloat and inefficiency?
As well as maintainability, readability, etc.
Re: (Score:3, Insightful)
You're funny. Both of these depend largely on the programmer writing the code.
Re: (Score:2, Funny)
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? (Score:5, Funny)
Then again, most of it is written by biologists.
You mean 'evolved by biologists'. They aren't strong believers in intelligent design.
Re: (Score:2)
While C certainly has it's flaws, maintainability isn't inherently one of them.
Re:The "C" for some field? (Score:5, Insightful)
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: (Score:2)
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? (Score:4, Insightful)
Re: (Score:2)
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? (Score:5, Insightful)
Re: (Score:2)
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: (Score:3)
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: (Score:2)
Funny, my definition of "superior" would be a language that gets the job done, and is readily and cheaply available.
Re: (Score:2)
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: (Score:3)
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: (Score:3)
My definition for success is success. C projects are getting beaten by other languages in the marketplace .
Re:The "C" for some field? (Score:4, Informative)
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? (Score:4, Interesting)
Re: (Score:2)
Like C#?
Sage (Score:5, Informative)
lush (Lisp Universal SHell) (Score:2)
Version 3f670da0 (Score:2)
What is that a hash of the source code?
Re:Version 3f670da0 (Score:5, Funny)
What is that a hash of the source code?
Careful... wouldn't want to give the Mozilla devs any ideas.
Re: (Score:2)
Re: (Score:2)
It's not git specific, all distributed versioning systems use hashes for versions.
Re: (Score:3)
FORTRAN? (Score:5, Interesting)
Re: (Score:2)
The main strength of this language seems to be easy paralellisation, which can lead to higher speeds for certain algorithms.
Re: (Score:2)
Re:FORTRAN? (Score:4, Informative)
Re:FORTRAN? (Score:5, Informative)
well.. apparently this "language" has modern fortran built in.
just open the link. there's some stats there. I don't envision huge popularity for this though.. unless he integrates/develops it into a fullblown mathlab competitor(that javascript does mandelbrot almost as fast is kind if peculiar though..). not as peculiar as "pi sum" bench being faster on javascript and julia than c++.
"The library, mostly written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, FFTs, and string processing. "
Re:FORTRAN? (Score:5, Interesting)
Second that. Modern FORTRAN kicks some serious butt and has a huge user and support base. Language snobs dismiss it as antiquated but they're usually referring to versions of the language that haven't been used since the 1980's. There are good reasons that current HPC developers use mostly FORTRAN and C, like good support for parallalization, global memory functions for clustering, and efficient compilers.
It's great that people make new tools and share them with others, but many times that effort could be put into making existing good tools even better.
Re: (Score:3, Insightful)
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
Re: (Score:3)
Re: (Score:3)
I should also say that MATLAB, R, and all the rest are real programming
Re:FORTRAN? (Score:4, Interesting)
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: (Score:2)
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-
Re: (Score:3)
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 base
Re:FORTRAN? (Score:5, Informative)
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? (Score:4, Informative)
Hey - at least Fortran does not rely on whitespace!
Re: (Score:2)
I'll hold it down. Get your gun.
rgb
Re: (Score:2)
People who have to look up FORTRAN on Wikipedia to find out what it is have no business recommending it.
Re: (Score:2)
My point is that there are languages that are mature that are capable of doing a lot of what people actually want to do already. If there are weaknesses in that language, a discussion on why replacing that language with another is h
Re: (Score:2)
In my experience, this type of discussion is rarely helpful.
You know, I like C. But I thi
Re: (Score:3, Insightful)
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: (Score:2)
Re: (Score:2)
Well you beat me to the post but yes Fortran 90 and beyond have all the features of "modern" languages and quite a bit more that are not found in other languages du jour. Instead of mocking people might do well to familarize themself with the current language and not keep talking about IV or 77.
Fortress (Score:2, Interesting)
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... (Score:2)
Forgot to mention the irony that one of the principal architects of Common Lisp was Guy Steele, who is now developing Fortress.
Re: (Score:2)
Offtopic, I know, but was there ever a more manly name than 'Guy Steele'? That may be better than Max Power, even.
Re: (Score:2)
Because new doesn't imply better. Sometimes something survives because it is good..
We still drive automobiles. They have improved over time, just like Fortran has improved over time too. But my car still has four wheels, an engine, pedals and a steering wheel - it's an automobile, and damn useful even 120 years later.
Sure, jet fighters, snowboards and Segways are newer technology, and well suited for their uses. But to get me from where I am to the neighboring town, a car is much faster. Neither of the
Re:Fortress (Score:5, Informative)
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: (Score:2)
I'm getting tired of saying this. Check out Fortran '08. Fully OOP.
APL? (Score:4, Insightful)
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. (Score:2)
"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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
FORTRAN has a bad rep.. it is a good language, but not very 'sexy', so it has fallen out of favor. Languages are, in many ways, a social contest... often having more to do with how many people are using it then the language's actual ability (since this impacts how easy it is to hire people).
Unfortunately there is also a high 'sexy' factor in creating new languages that do the same things as old ones, solving t
Re: (Score:2)
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.
It's the packages stupid! (Score:5, Interesting)
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: (Score:2)
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: (Score:2)
Re: (Score:3, Insightful)
Absolutely right. It is important to recognize that both Matlab and R are much more than just languages. I would also throw Mathematica into the mix too, while it is a bit slower than Matlab, its numerical capabilities have continued to grow and it incorporates a fine statistics package alongside a quality plotting and graphics package (not to mention its symbolic roots and recent introduction of dynamic gui manipulation).
For julia to be successful it needs robust integration with quality addon packages, st
Re: (Score:2)
I could not agree more.
Let's face it, Perl is an abysmal language by itself. (Yes, the regex engine is good, but that's about it IMHO.) Add in CPAN though, and you've got a massive wealth of libraries to use. The pain becomes worthwhile.
Numerical Python (Score:5, Informative)
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: (Score:3)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
I think you totally missed the point. You can use sequences and lists in Matlab too, try to imagine it with different numbers.
Re: (Score:2)
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: (Score:2)
I mostly use python these days [snip] Matlab's syntax is just so slick by comparison:
Matlab: foo = [1 2;3 4] Python: foo= array([[1,2],[3,4]]) R: foo - matrix(c(1,2,3,4),2,2)
NumPy includes a matrix library: foo=mat('1 2;3 4'). In general, Python's syntax beats Matlab's syntax
hands down. (In this particular case there is almost a tie, but a trivial advantage for Matlab. I spend apporximately 0% of my time typing in data for array construction, and I suppose that is true of most users.) For help transitioning, see http://www.scipy.org/NumPy_for_Matlab_Users [scipy.org].
Re: (Score:2)
just throw your whole project in pypy, woop, instant speed boost. (in my case 4-5x faster)
Does Karpinski have a beard? (Score:2)
Also is this named after the same Julia that worked with fractals? Julia Ref [wikipedia.org]
Re: (Score:2)
I already dislike it (Score:3)
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: (Score:2)
Although I agree, it's a PITA as most people don't use its matrix handling capabilities.
Statistics in Matlab is frustrating? (Score:2)
Yet another language (Score:2)
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: (Score:2)
It even looks vaguely like JavaScript, so why bother?
Because JavaScript.
Pretty (Score:2)
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: (Score:2)
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 (Score:2)
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: (Score:2)
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? (Score:2)
surely when talking about speed they mean (Score:3)
Not fast at all (Score:4, Informative)
They want to design a language for speed, but they already made choices in the language that hamper speed dramatically, like dynamic typing. Dynamic typing adds overhead to every function call; it's fine if your functions do a lot of work, not so much if they do relatively little and are called very often.
It looks like if you want to write fairly low-level code, you'll still need to write it in C there...
It also looks like their approach to parallelization is very heavy-weight and, albeit usable in clusters, it will yield both poor scalability on large systems and poor performance on simple multi-core systems.
There is already a high-level, dynamic and accessible language for numerical computing, it's MATLAB. It wraps a lot of high-performance libraries, using them without the user even noticing it. Code in MATLAB can easily be faster than in C for some constructs because C compilers, unlike MATLAB, do not recognize some patterns and replace them by optimized library calls. For this reason, MATLAB is great when you're coding with high-level constructs, but suffers from poor performance when using low-level constructs (such as accessing data element by element) for the same reasons as pointed out above.
A new language for high-performance numerical computing should allow both the high-level programming of MATLAB and the possibilities of a low-level statically compiled language like C. The best contender for this is C++, which has tons of high-level and fast libraries for transcendental functions, linear algebra, statistics, image processing, signal processing, etc.
As for FORTRAN, it's great for writing one thing well and fast, but it doesn't have any mechanisms for more high-level programming or code re-use, which means it is annoying to maintain, extend, or to even guarantee consistencies between the different subroutines of a large application. It also relies a lot more on what the compiler will do, while with C/C++ there is more control on what happens with regards to vectorization, parallelization or data transfers, which can be critical for heterogeneous systems.
Re: (Score:3, Insightful)
Dynamic typing doesn't add any overhead when you can determine which specific method you need when generating code — which, in a dynamic language with a JIT, is very late, meaning that you can most of the time. Julia uses tons of small method definitions that call other small methods and so on, even for basic things like adding two integers, but the compiler is smart enough to compile addition into a single machine instruction. The notion that dynamic languages are slow because of their dynamism is ve
Re: (Score:3)
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.
Where did I say otherwise? I talked about *control* of performance, not performance that is obtained with default, automatic an
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Why does the Oblig always misses the <a [xkcd.com]> 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.
Not This Again (Score:4, Informative)
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: (Score:3)
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 (Score:4, Insightful)
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: (Score:3)
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 s
Re: (Score:2)
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: (Score:2)
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.
Why don't scientists use functional languages? (Score:3)
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 programme