On Friday, May 1, 2015 at 12:38:33 PM UTC-4, Jeff Bezanson wrote: > > Steven -- I agree and I find it very refreshing that you're willing to > judge a language by more than just performance. Any given language can > always be optimized better, so ideally you want to compare them by > more robust criteria. > > Obviously a particular system might have a well-tuned library routine > that's faster than our equivalent. But think about it: is having a > slow interpreter, and relying on code to spend all its time in > pre-baked library kernels the *right* way to get performance? That's > just the same boring design that has been used over and over again, in > matlab, IDL, octave, R, etc. In those cases the language isn't > bringing much to the table, except a pile of rules about how important > code must still be written in C/Fortran, and how your code must be > vectorized or shame on you. >
That's a very good point... and is one of the things I like a lot about Julia... Even with my initial surprise about a single performance issue (the building up a string by concatenation), I did NOT judge Julia by that alone, and have been quite happy with it overall [and I've been converting all of the developers at the startup where I'm consulting to Julia fans]. I also have faith, from what I've seen so far, is that performance issues *will* be addressed, as best as possible considering the architecture and goals of the language, by a number of pretty smart people, both in and outside of the "core" team. Scott
