On Friday, May 1, 2015 at 5:23:40 PM UTC, Steven G. Johnson wrote: > > On Friday, May 1, 2015 at 1:12:00 PM UTC-4, Steven Sagaert wrote: >> >> That wasn't what I was saying. I like the philosophy behind julia. But in >> practice (as of now) even in julia you still have to code in a certain >> style if you want very good performance and that's no different than in any >> other language. >> > > The goal of Julia is not to be a language in which it is *impossible* to > write slow code, or a language in which all programming styles are equally > fast. The goal (or at least, one of the goals) is to be an expressive, > high-level dynamic language, in which it is also *possible* to write > performance-critical inner-loop code. >
*Summary* Thanks (all) for answering. I agree that *possible* to write fast code is a goal. I believe that has been achieved. Nobody commented much on my list of concerns.. Yes, of course *impossible* to write slow code is a very high bar.. I just thought Python - an interpreted language - wasn't a high bar :) I'm just using that as a comparison. I would like (newbie) Julia code not be beaten by (core language) Python. Or not at least by much (a constant factor). Has that been achieved? I noticed the "yes/no" answer on "Any". Global no longer a problem? Yes, gets you slow code but compared to Python? Tuples/Dict now as fast? [I just noticed Named tuples thread.] Then there are of course, say, Python libraries that are "faster" to non-exciting Julia ones.. My hope is through PyCall you can use them all (I understand that to be the case) - without speed penalty. We may still have the two/N-language problem for a while, for functionality reasons but not speed-reasons.. The dual Julia/Python is much preferred "problem" I think to Julia/C or Python/C.. and gets you all the "batteries included" you would want (speaking as a "non-math" user). Great to see that strings are being worked on, I never wanted this thread to be just about "one thing". I can now see how RefCounting in Python helps strings.. I'm also looking into how to beat Python there.. > That *is* different from other high-level languages, in which it is > typically *not* possible to write performance-critical inner-loop code > without dropping down to a lower-level language (C, Fortran, Cython...). > If you are coding exclusively in Python or R, and there isn't an optimized > function appropriate for the innermost loops of your task at hand, you are > out of luck. >
