Groups 53 of 99+ julia-users › What's the reason of the Success of Python? 36 posts by 21 authors Sisyphuss 9/29/15 While waiting Julia 0.4 stabilizing, let's do some brainstorming. What's the reason of the Success of Python? If Julia had appeared 10 years earlier, will Python still have this success? Tomas Lycken 9/29/15 One thing Python does well, which Julia doesn't (yet) succeed in, is make it easy to start coding from zero experience and get something that executes "well enough" (although, as always with first-time coders, code organization and readability might still leave some things to wish for...). In Julia, it's very much possible to get something to run, but the performance differences between well-written and not-so-well-written code are *huge*. This means that most users will show their code to someone who knows more than they do, and more likely than not get a first reaction along the lines of "everything you do is wrong". Although the statement isn't untrue, it's very off-putting - and even more off-putting is the fact that there's a lot of "computer sciencey" stuff you need to understand to be able to grasp *why* you did it wrong (type stability, difference between abstract and leaf types, difference between anonymous and named functions etc). Don't get me wrong - I think Julia is doing a lot of things right, and I'm glad that these "CS-y" questions are asked and handled up-front: this is what gives Julia much of its power. Hopefully, much of the performance difference between hacked-together-rubbish code and well-polished code will be eradicated by version 1.0, and we'll see how popular Julia becomes then. Currently, though, the success of any general programming language or tool seems to hinge mostly on what you can build with it (Objective C is ugly as hell, but it was, until very recently, the only way to build iPhone apps so people learned anyway. Similarly, everyone seems to know a little JavaScript these days, despite all its quirks...). I think the success of Julia, outside of the scientific computing niche, will depend mostly on where (as in on what platforms) Julia 1.0 can be executed. // T - show quoted text - 0 0 Páll Haraldsson 9/29/15 On Tuesday, September 29, 2015 at 10:20:18 AM UTC, Tomas Lycken wrote: One thing Python does well, which Julia doesn't (yet) succeed in, is make it easy to start coding from zero experience and get something that executes "well enough" I think, this may be a little unfair to Julia. Python (and Perl) succeeded not because it is fast (only because it has fast development times - to begin with at least). Julia is expected to be fast, compared to C, Python isn't. Even if Julia were as slow as Python, it seems to be a better language - more maintainable, as more static and doesn't really have duck-typing (and Hoare's "billion dollar mistake"), right? (although, as always with first-time coders, code organization and readability might still leave some things to wish for...). In Julia, it's very much possible to get something to run, but the performance differences between well-written and not-so-well-written code are *huge*. Right, but even your code that is written to be slow should work (no segfaults..) and not be slower than Python? At least, those would be exceptional cases, all that I would like to know about as I see no good reason for it. The way I see it, yes, type-instability makes your code way slower, but isn't that (roughly) the same as in Python, where all code is "type-unstable", because of duck-typing? That is or was at least the default. Now PyPy and Numba etc. helps (that didn't exist in the beginning/10 years ago) This means that most users will show their code to someone who knows more than they do, and more likely than not get a first reaction along the lines of "everything you do is wrong". Although the statement isn't untrue, it's very off-putting - and even more off-putting is the fact that there's a lot of "computer sciencey" stuff you need to understand to be able to grasp Only for fast code, not "correct" code. And 90% of code isn't speed-critical. To a beginner this seems very good. First you learn the basics. You can prototype and later optimize ("premature optimization is the root of all evil"?). *why* you did it wrong (type stability, difference between abstract and leaf types, difference between anonymous and named functions etc). Don't get me wrong - I think Julia is doing a lot of things right, and I'm glad that these "CS-y" questions are asked and handled up-front: this is what gives Julia much of its power. Hopefully, much of the performance difference between hacked-together-rubbish code and well-polished code will be eradicated by version 1.0, and we'll see how popular Julia becomes then. Currently, though, the success of any general programming language or tool seems to hinge mostly on what you can build with it (Objective C is ugly as hell yes.. You can actually call Objective-C (OS X) from Julia.. I think Android support should come first, then iOS support. Neither should be too hard, possibly Apple would object.. -- Palli. 0 0 Tomas Lycken 9/29/15 I think, this may be a little unfair to Julia. I agree that it’s unfair - but new users are seldom fair. What I meant to get at was not that Julia code by an inexperienced programmer is worse than anything else, but just that since Julia can be so fast, I think there’s a big risk that the gap between potential and actual throughput in many “first real Julia program”s becomes an annoyance, even if Julia has a the potential to reach further than Python ever could. In other words, it’s not Julia’s actual performance that is the problem, but the way it differs from expectations. // T - show quoted text - 0 0 Tom Breloff 9/29/15 Re: [julia-users] Re: What's the reason of the Success of Python? One of the recent "why is my code slow" posts from a new user had a statement that was something along the lines of "sure it's still 4-5 times faster than python, but I expected it to be much faster". I think this sums it up... new users hear of Julia's blazing speed and expect it to be as fast as highly optimized C/Fortran with absolutely zero effort. I think a great sales pitch for Julia could come in the form of a contest... pick several programming problems, and choose your language. For each problem, you get 1 point for finishing it first (correctly), and 1 point for the fastest execution time. What language would you choose? - show quoted text - 3 0 Scott Jones 9/29/15 Re: [julia-users] Re: What's the reason of the Success of Python? Yes, one of the things that won me over was that I could write many fewer lines of code that I'd have to do in C/C++/Java (and that was when I was still a total novice - which I still am in many ways, but getting better). Python has been successful IMO because it's easy to quickly get stuff up and running - not like C/C++/Java, and Julia can be the same. I like Tom's idea - I'd maybe rank things based on: getting correct results (most important), time to do the programming, lines of code (that can have a big effect on maintainability) [might have to be some rules though, so people don't put everything on one line, maybe count statements, not lines]), and execution time. Code that doesn't get 100% correct results would not even be considered, and the other 3 metrics would be weighted, to determine the winner(s). - show quoted text - 1 0 Tom Breloff 9/29/15 Re: [julia-users] Re: What's the reason of the Success of Python? Leave it to Scott to make things more complicated... :) - show quoted text - 1 0 Scott Jones 9/29/15 Re: [julia-users] Re: What's the reason of the Success of Python? On Tuesday, September 29, 2015 at 10:14:48 AM UTC-4, Tom Breloff wrote: Leave it to Scott to make things more complicated... :) Of course! :) I just wanted it to reflect better which language might do better for a company, where the programmer's time may be worth a lot more than the execution time (both to initially implement a correct solution, but also to maintain it). Generic (multi-dispatch) programming a la Julia I think can be a big win there - giving you maybe more of what (single dispatch) OO programming has always promised, but not really delivered that well, good code reuse. 0 0 Edmondo Giovannozzi 9/29/15 First of all I want to say that you are doing an excellent job. I program in Fortran and python but I'm keeping an eye on Julia, I haven't decided to switch yet. I'm not afraid to learn a new language, so I may do it in the future. Python is slow, but most of the time I use vectorized instruction (with numpy), it is quite fast for what is needed (elaboration of experimental data). The python matplotlib graphics package is amazing. I know that it can be used from Julia, but when I tried it took some seconds to import it (not a big issue, but when you want to use it interactively it can). We have also lot of code already written in Python. That's not necessary a problem as once we already switched from Matlab to Python). If the speed is needed I can use Fortran, as it is quite easy to link a Fortran procedure to Python with f2py. The other pointed cited was true, when I tried to do something fast, I couldn't do it fast the first time (at the end I find a way to speed it up and was even faster than its Fortran equivalent). A lot of programs we have are mainly simulation program already written in Fortran so we may have to stick to it. There are also a couple of things, one is the use of the matlab points operator .*, ./, etc. Well I don't think it was really a good idea (at least for me). Most of the time all the operations I need are just point (how yo call them?) one and only few of them are really matrix operations. Of course it is not something that will keep me away from Julia but if there were ever be in future the possibility to change that behaviour.... (a daydream) I also liked a lot the possibility in numpy to add an axes to an array with the keyword numpy.newaxis. But I'm quite sure that wouldn't be a problem to add it to Julia (if it's not already possible of course, I'm waiting the final release of Julia 0.4 in order to have a new look at the new features). The other suggestion is to speed up vectorized instructions. The fact that in the manual is written to write explicit loops in places where even in Fortran one wouldn't have used loops anymore is a drawback. And last, it is psychological, but one is always waiting for the first stable release.... (when the 1.0...?) By the way I'm eager for the 0.4 release, I'll install it and I'l let you know my impressions. 0 0 Christoph Ortner 9/29/15 Re: [julia-users] Re: What's the reason of the Success of Python? I prefer Julia to Python for many reasons, not only performance, but purely regarding performance I often wondered: How much is the poor Python performance just a current state. In fact NUMBA can often take care if it in a very low-effort way. (a) What is numba lacking now, compared to Julia (performance-wise) (b) Would it be realistic to assume that a "Python 4" might be built on top of similar architecture as Julia and hence yield similar performance? Or is there something special about Julia's design? Thanks, Christoph 1 0 Scott Jones 9/29/15 Re: [julia-users] Re: What's the reason of the Success of Python? Well, I do think there is a lot special about Julia's design that could not be added on to Python - the macro programming, multiple dispatch capabilities and the powerful type system (hopefully with traits built into the language in the future!) are what most set it apart from other languages, in my mind. Those characteristics make it possible to write a very small amount of code, but have the compiler do the work of making highly optimized versions of a function - and do so at compile-time, not run-time (and if a function is called with types that it hasn't seen before, well, it's JITed, so you still have the dynamic nature that makes languages like Python so appealing to people). Best of both worlds, IMO. Keno's work is also making it more and more easy to directly call into C++, so if you have big libraries of optimized C++ code, you can just use them. All good! (Yes, there's a lot more work that needs to be done, but the fundamentals of Julia are superb). Scott - show quoted text - 1 0 Steven G. Johnson 9/29/15 On Tuesday, September 29, 2015 at 12:42:04 PM UTC-4, Edmondo Giovannozzi wrote: First of all I want to say that you are doing an excellent job. I program in Fortran and python but I'm keeping an eye on Julia, I haven't decided to switch yet. I'm not afraid to learn a new language, so I may do it in the future. Python is slow, but most of the time I use vectorized instruction (with numpy), it is quite fast for what is needed (elaboration of experimental data). The python matplotlib graphics package is amazing. I know that it can be used from Julia, but when I tried it took some seconds to import it (not a big issue, but when you want to use it interactively it can). (It's a lot faster now that we have precompiled packages. Down from 30 seconds to 4 seconds on my machine. Future improvements in precompilation should bring this down further, although there is a limit because it needs to do runtime initialization of Python and Matplotlib, and even in Python it takes more than 1s to load Matplotlib on my machine.) We have also lot of code already written in Python. That's not necessary a problem as once we already switched from Matlab to Python). If the speed is needed I can use Fortran, as it is quite easy to link a Fortran procedure to Python with f2py. The other pointed cited was true, when I tried to do something fast, I couldn't do it fast the first time (at the end I find a way to speed it up and was even faster than its Fortran equivalent). A lot of programs we have are mainly simulation program already written in Fortran so we may have to stick to it. There are also a couple of things, one is the use of the matlab points operator .*, ./, etc. Well I don't think it was really a good idea (at least for me). Most of the time all the operations I need are just point (how yo call them?) one and only few of them are really matrix operations. Of course it is not something that will keep me away from Julia but if there were ever be in future the possibility to change that behaviour.... (a daydream) I also liked a lot the possibility in numpy to add an axes to an array with the keyword numpy.newaxis. But I'm quite sure that wouldn't be a problem to add it to Julia (if it's not already possible of course, I'm waiting the final release of Julia 0.4 in order to have a new look at the new features). The other suggestion is to speed up vectorized instructions. The fact that in the manual is written to write explicit loops in places where even in Fortran one wouldn't have used loops anymore is a drawback. And last, it is psychological, but one is always waiting for the first stable release.... (when the 1.0...?) By the way I'm eager for the 0.4 release, I'll install it and I'l let you know my impressions. 0 0 Daniel Carrera 9/29/15 On Tuesday, 29 September 2015 12:20:18 UTC+2, Tomas Lycken wrote: One thing Python does well, which Julia doesn't (yet) succeed in, is make it easy to start coding from zero experience and get something that executes "well enough" (although, as always with first-time coders, code organization and readability might still leave some things to wish for...). You don't think Julia does that? In Julia, it's very much possible to get something to run, but the performance differences between well-written and not-so-well-written code are *huge*. But not-so-well written Julia code should be at least as fast as Python. Don't you think so? This means that most users will show their code to someone who knows more than they do, and more likely than not get a first reaction along the lines of "everything you do is wrong". I don't think that this is more true for Julia than other languages. In Python you have to worry about indentation, and they have their own conventions about how things work. Every language has some learning curve. I think Julia's is shallow. Then again, maybe I only think that because I learned many languages before Julia. and even more off-putting is the fact that there's a lot of "computer sciencey" stuff you need to understand to be able to grasp *why* you did it wrong (type stability, difference between abstract and leaf types, difference between anonymous and named functions etc). You can get Python-like performance without getting computer-sciency. But any program that achieves good performance requires you to learn some computer-sciency stuff. People who understand how computer hardware works, or how algorithms work, will always have some advantage over those who don't. I don't think any language will ever compensate for programmer skill. I don't think it's fair to expect Python-like effort to produce C-like performance. Don't get me wrong - I think Julia is doing a lot of things right, and I'm glad that these "CS-y" questions are asked and handled up-front: this is what gives Julia much of its power. Hopefully, much of the performance difference between hacked-together-rubbish code and well-polished code will be eradicated by version 1.0, and we'll see how popular Julia becomes then. How do you envision that happening? I understand that compilers can get better, but no compiler will ever replace your algorithm by a cache-friendly alternative. Cheers, Daniel. 0 0 Daniel Carrera 9/29/15 On Tuesday, 29 September 2015 14:50:14 UTC+2, Páll Haraldsson wrote: Even if Julia were as slow as Python, it seems to be a better language - more maintainable Exactly! I never liked Python. I use Julia because I like the language itself. The fact that it is fast is actually secondary, and mainly just allows me to solve problems that I otherwise might have solved with Fortran or left unsolved. Before Julia, I used Octave. I knew that Octave was probably slower than NumPy, but I didn't care. Only for fast code, not "correct" code. And 90% of code isn't speed-critical. To a beginner this seems very good. First you learn the basics. You can prototype and later optimize ("premature optimization is the root of all evil"?). Also, a lot of important problems are not speed-sensitive. I use Julia to analyze simulation results. I use it mainly because it is a very agile language; I can try to look at the data in different ways. Cheers, Daniel. 0 0 Tomas Lycken 9/30/15 You don’t think Julia does that? […] But not-so-well written Julia code should be at least as fast as Python. Don’t you think so? Yes, I do think so (but there are still lots of examples of new users who manage to write Julia code that’s slower by orders of magnitude compared to almost-equivalent Python - just search this list for “slower python”). However, the main problem here, IMO, is not Julia’s actual performance, but the difference between expected and actual performance in new users’ first programs. In other words, the problem is not that Julia is slower than Python - it mostly isn’t - but that Julia is (much) slower than the user expects it to be. You can get Python-like performance without getting computer-sciency. Again, the problem is not reaching Python-like performance, but rather not beating Python by enough. How do you envision that happening? Three of the most common performance issues in beginner Julians’ programs, are executing code in global scope, type instabilities for other reasons, and unnecessary array allocations due to writing code in vectorized form (similar to what one needs to do in Matlab to be performant). For the first two, the compiler can probably not make the code more performant just out-of-the-box, but it can probably become better at warning the user when they are doing something inefficient, e.g. emit a warning message when code is compiled (or, in the REPL, when it’s executed) that there’s a type instability problem, so that new users don’t have to turn to the list for help on making their code fast; the compiler points their problem out for them and helps them fix it. For the last problem (array allocations), I expect that the changes to array behavior in 0.5 will help mitigate much of this. There are still things to be wary of - for example, a statement like d = a .* b + c, where a, b and c are equal-sized arrays, has to allocate a temporary array for a .* b before adding the result to c and assign it to d. If the arrays are large, this would of course be quite expensive, but the compiler could be smarter here, and I know that the core team knows about this and have discussed various solutions. Improvements here will probably have a large impact on performance of newbie programs especially, since many programmers come from environments where vectorization is the only way to get good performance (Matlab, NumPy etc). These changes are not related to algorithm complexity, cache-friendliness or anything else computer-sciency, but in fact are things where the language, if it were “smarter”, could sometimes compensate for the programmers’ lack of deep knowledge. Fixing them will help newbies write code that, even if it’s not even near C speed, is at least a couple of times faster than Python. Note: since I am in no way involved in (or capable of) making changes like these happen, read the above paragraphs more as a wishlist from a simple user than anything else. I don’t even know if my estimates of feasibility are reasonable… Also, a lot of important problems are not speed-sensitive. Of course. And I still think Julia is a fantastic language for many things that are not. But I also think that one of the main selling points, at least at the moment, is the combination of speed and simplicity; if you only need the latter, you might as well decide on something with wider adoption (although I’m glad you didn’t :) ). // T - show quoted text - 0 0 Andreas Lobinger 9/30/15 Hello colleagues, On Tuesday, September 29, 2015 at 11:30:19 AM UTC+2, Sisyphuss wrote: While waiting Julia 0.4 stabilizing, let's do some brainstorming. btw: it's not "waiting for Julia 0.4 stabilizing", the correct thing is: While we test release candidates of Julia 0.4 to help it stabilizing, let's ... What's the reason of the Success of Python? Productivity. Using python and even only the standard library you can solve a long list of data or computing problems with really low effort and in most cases few LOC. At the same time you have to sacrifice raw speed, but that's the main difference between a compiler and interpreted runtime. If Julia had appeared 10 years earlier, will Python still have this success? Success yes, but the user base would be way smaller. Python has the plus of a very simple object oriented model and i think this is/was easier for people to follow than other concepts of encapsulation. 0 0 Tamas Papp 9/30/15 Re: [julia-users] Re: What's the reason of the Success of Python? On Wed, Sep 30 2015, Tomas Lycken wrote: > You can get Python-like performance without getting computer-sciency. > > Again, the problem is not reaching Python-like performance, but rather *not > beating Python by enough*. Raw speed is a red herring. For many applications it is not the most relevant factor --- scientific computing is one of the exceptions, but even there a lot of code is used just a few times, for solving a specific problem, where coding time dominates. Python has the following key strengths: 1. you can prototype code very quickly, 2. you can rely on a lot of existing mature libraries, 3. with very little effort, you can _write_ your own libraries. Of course these all interact, but 3. is probably the most important. R is much more quirky when it comes to writing robust library code, but still very widespread in the statistics community because of 1. and 2. Don't get me wrong, speed is important too. But I get the impression that people discuss speed benchmarks a lot because this is something that can be boiled down to numbers (how meaningful they are is, of course, another question), while 1-3. above are very hard to quantify. Best, Tamas 0 0 Andrei Zh 9/30/15 Coming back to the original question about success of Python, I'd stress these points: * it's simple. for both - programmers and non-programmers * it's a system language for most Unix-like operations systems * it has very strong scientific stack (read as: has a lot of mature scientific libraries) * it's good for web programming So 3 out of 4 are libraries (read as: tools for solving problems in specific areas). For Julia I can think of only 2 things: * it's perfect for writing your own scientific libraries * it's just awesome programming language But nobody will "buy" it just for the second point - you need to try it first to understand - so we have only one. And community of people making science and writing their own libraries is tiny (compared to, say, web programmers). Is there any other niche we can (or should) occupy? P.S. Yes, I believe we need to explicitly promote Julia, because most programmers don't even know about it or have too little understanding to give it a try. - show quoted text - 0 0 Matthew Pearce 9/30/15 One big pull for python is the ecosystem. Almost any task has a python package available. However, there are gaps. For all the strength of scipy + numpy, there are serious gaps. For instance in methods for sparse matrices, and CUDA bindings. It's those gaps that brought me here. Also, pip is not consistently used across packages (e.g. pyQT). This is due to it having evolved from a less well structured system. Julia seems to have learned a bunch of lessons from this; but generally making package management _really_ easy both on supply and consumption will be an advantage for it. Matthew - show quoted text - 0 0 Christian Peel 9/30/15 Re: [julia-users] Re: What's the reason of the Success of Python? One could also ask what the reason for the success of Matlab and R; I don't know R, but I can speak a bit about Matlab. 1) Matlab has great high-level vectorized notation. If you're a student or engineer, it's dramatically easier to solve a linear system in Matlab (x=inv(A)*b) than it is in many other languages. Julia has at least this same level of friendliness and high-level notation. 2) The Mathworks has a wide variety of toolboxes and there is also quite a bit of open-source Matlab code out there. Julia lags here, but is catching up. 3) Matlab is easy to hack in. I have seen engineers (me included) do everything from ugly-but-workable bit-level simulation of hardware to large simulatons of an LTE basestation; the reason it's used is just because it's easy to hack, or to write quick-and-dirty code. In addition to the notation and toolboxes, the easy-to-hack nature comes from the interpreted nature of Matlab (or JIT behind the scenes), and automatic inclusion of files which were changed. Of course the Julia JIT has more to do that the Matlab JIT/interpreter, yet I'd still love for it to be faster. I'd also love for something like Autoreload.jl to be built right into the REPL so that I don't have to do any 'include', 'require', or anything at all after changing a file, but just to run it. - show quoted text - -- chris...@ieee.org 0 0 Tamas Papp 9/30/15 Re: [julia-users] Re: What's the reason of the Success of Python? On Wed, Sep 30 2015, Christian Peel wrote: > 1) Matlab has great high-level vectorized notation. If you're a student or > engineer, it's dramatically easier to solve a linear system in Matlab > (x=inv(A)*b) than it is in many other languages. Julia has at least this You shouldn't ever do this (in either Julia or Matlab, or any language), it is ill-conditioned for general matrices. I think the Matlab function is linsolve. > 3) Matlab is easy to hack in. I have seen engineers (me included) do > everything from ugly-but-workable bit-level simulation of hardware to large > simulatons of an LTE basestation; the reason it's used is just because it's Matlab has a quite user-friendly stepping debugger, which is a must for many people. Julia has a long way to go (there has been recent progress). best, Tamas 0 0 Michele Zaffalon 9/30/15 Re: [julia-users] Re: What's the reason of the Success of Python? On Wed, Sep 30, 2015 at 4:32 PM, Tamas Papp wrote: On Wed, Sep 30 2015, Christian Peel wrote: > 1) Matlab has great high-level vectorized notation. If you're a student or > engineer, it's dramatically easier to solve a linear system in Matlab > (x=inv(A)*b) than it is in many other languages. Julia has at least this You shouldn't ever do this (in either Julia or Matlab, or any language), it is ill-conditioned for general matrices. I think the Matlab function is linsolve. There is some literature supporting the opposite: http://arxiv.org/pdf/1201.6035.pdf 0 0 Tamas Papp 9/30/15 Re: [julia-users] Re: What's the reason of the Success of Python? - show quoted text - Fascinating, thanks, I didn't know about this. I have to give the paper a careful reading, but a canonical example is function hilbert(n) H = Array(Float64,n,n) for i = 1:n for j = 1:n H[i,j] = 1/(i+j-1) end end H end h = hilbert(12) b = collect(1:12) x1 = h\b x2 = inv(h) * b (maximum(abs(h*x1-b)),maximum(abs(h*x2-b))) # evaluates to (1.1324882507324219e-6,1.2540735006332397) Best, Tamas PS: apologies for off topic in the thread. 0 0 Art Kuo 9/30/15 Re: [julia-users] Re: What's the reason of the Success of Python? > (x=inv(A)*b) than it is in many other languages. Julia has at least this You shouldn't ever do this (in either Julia or Matlab, or any language), it is ill-conditioned for general matrices. I think the Matlab function is linsolve. Perhaps more precise to say "A\b is always faster than inv(A)*b, and more accurate if A is ill-conditioned." I also usually prefer Matlab's backslash or mldivide, A\b, over the more specific linsolve, because backslash chooses the right solver (including linsolve) most of the time, for systems that are sparse, over- or under-determined, etc. Julia also implements similar functionality, but I doubt if it is as optimized as Matlab, which has many years' advantage. As for the accuracy advantage, it is true that inv(A)*b can go wrong, and A\b will go less wrong. But Ill-conditioned A is usually an indicator that neither approach will be great. 0 0 David Anthoff 9/30/15 RE: [julia-users] Re: What's the reason of the Success of Python? When you have matrices with special structures and symmetries, Julia can encode that information in the type of the matrix, and in those cases the backslash operator should actually be more efficient than in Matlab because there is no need to “guess” what the best algorithm might be. My understanding is that no such thing exists in Matlab. Having said that, take this with a grain of salt, this is not my area of expertise (neither in Julia nor in Matlab). The relevant Julia manual section is http://docs.julialang.org/en/latest/manual/linear-algebra/. From: julia...@googlegroups.com [mailto:julia...@googlegroups.com] On Behalf Of Art Kuo Sent: Wednesday, September 30, 2015 9:30 AM To: julia-users Subject: Re: [julia-users] Re: What's the reason of the Success of Python? - show quoted text - 0 0 Hai Nguyen 9/30/15 Re: [julia-users] Re: What's the reason of the Success of Python? I myself do not care much about Julia or python speed since I can write fast code in Cython (C/C++ speed with Python syntax sugar). There are several features in Julia I like much (and I think they can be good selling points). * CFFI: great that we can call C function easily. * Parallel: I very like Julia parallel syntax. Never tried to write Julia parallel code but once I read the code, just have feeling that the parallel usage is very natural * macro: @time bla_bla --> I like the macro in the same line * Julia syntax for computing is much more concise than python. Things I don't like in Julia * developers and user encourage to use 'using' to import all methods. I prefer to see exporting importing in Python (from numpy import dot, ...) * Julia's string stuff seems very strict to me. For example I wish Julia has: a = "my 1st string; b = 'my 2nd string', c = a + b * declare type by `x::Int`. I myself prefer to use 'x : int' typehint in Python3.5. * warming up time in Julia is still slow for me. Hai On Wed, Sep 30, 2015 at 1:01 PM, David Anthoff wrote: When you have matrices with special structures and symmetries, Julia can encode that information in the type of the matrix, and in those cases the backslash operator should actually be more efficient than in Matlab because there is no need to “guess” what the best algorithm might be. My understanding is that no such thing exists in Matlab. Having said that, take this with a grain of salt, this is not my area of expertise (neither in Julia nor in Matlab). The relevant Julia manual section is http://docs.julialang.org/en/latest/manual/linear-algebra/. From: julia...@googlegroups.com [mailto:julia...@googlegroups.com] On Behalf Of Art Kuo Sent: Wednesday, September 30, 2015 9:30 AM To: julia-users Subject: Re: [julia-users] Re: What's the reason of the Success of Python? > (x=inv(A)*b) than it is in many other languages. Julia has at least this You shouldn't ever do this (in either Julia or Matlab, or any language), it is ill-conditioned for general matrices. I think the Matlab function is linsolve. Perhaps more precise to say "A\b is always faster than inv(A)*b, and more accurate if A is ill-conditioned." I also usually prefer Matlab's backslash or mldivide, A\b, over the more specific linsolve, because backslash chooses the right solver (including linsolve) most of the time, for systems that are sparse, over- or under-determined, etc. Julia also implements similar functionality, but I doubt if it is as optimized as Matlab, which has many years' advantage. As for the accuracy advantage, it is true that inv(A)*b can go wrong, and A\b will go less wrong. But Ill-conditioned A is usually an indicator that neither approach will be great. 0 0 Daniel Carrera 10/1/15 Re: [julia-users] Re: What's the reason of the Success of Python? On 30 September 2015 at 16:23, Christian Peel wrote: One could also ask what the reason for the success of Matlab and R; I don't know R, but I can speak a bit about Matlab. 1) Matlab has great high-level vectorized notation. If you're a student or engineer, it's dramatically easier to solve a linear system in Matlab (x=inv(A)*b) than it is in many other languages. Julia has at least this same level of friendliness and high-level notation. You should not be solving linear equations that way. You should be using "x = A \ b". Your method is less numerically stable (easier to get wrong answers) and computationally expensive. Instead of computing a matrix inverse, a linear system should be solved with QR factorization (or similar) which is what the " \ " operator does. Julia has the same operator. Daniel. 0 0 Daniel Carrera 10/1/15 Re: [julia-users] Re: What's the reason of the Success of Python? On 30 September 2015 at 16:57, Michele Zaffalon wrote: There is some literature supporting the opposite: http://arxiv.org/pdf/1201.6035.pdf I know from experience that "x = inv(A)*b" gets answers wrong in places where "x = A \ b" gets them right. I show an example of this to my students every year (I don't feel like digging up my lecture notes right now). It is not simply about the condition number; a matrix inverse requires more arithmetic operations and machine error builds up. Daniel. 0 0 Christian Peel 10/1/15 Re: [julia-users] Re: What's the reason of the Success of Python? I completely agree with those who suggested use of "x = A\b" instead of x=inv(A)*b. Do any of you have comments on things that can be done to make Julia more 'hackable' and even easier to use? Am I alone in wishing for functionality such as that in Autoreload.jl [1] that is transparently built into the REPL? [1] https://github.com/malmaud/Autoreload.jl - show quoted text - -- chris...@ieee.org 0 0 Daniel Carrera 10/2/15 Re: [julia-users] Re: What's the reason of the Success of Python? I didn't know about Autoreload.jl; thanks for the tip. I currently do something similar using `include()`. I have a file called `lib.jl` that is nothing but a long list of `include` instructions for every file I work on. So I am constantly running `include("lib.jl")` in the REPL. Do you have any suggestions to make Julia more hackable? I don't know what you mean by that. Cheers, Daniel. - show quoted text - 0 0 SVAKSHA 10/2/15 Re: [julia-users] Re: What's the reason of the Success of Python? On Fri, Oct 2, 2015 at 7:05 AM, Daniel Carrera wrote: > nothing but a long list of `include` instructions for every file I work on. > So I am constantly running `include("lib.jl")` in the REPL. Isnt it possible to achieve the same result with a .juliarc file for each repo - the advantage being you only load the libs that repo needs as opposed to the entire list of libraries in `lib.jl`? SVAKSHA ॥ http://about.me/svaksha ॥ 0 0 Daniel Carrera 10/2/15 Re: [julia-users] Re: What's the reason of the Success of Python? - show quoted text - No, you didn't understand me. I don't have a bunch of repos with individual libraries. I have my own program that is a big stack of functions that I use to analyze the results of my simulations. I am constantly adding or rewriting functions. A lot of my daily work consists of going back and forth between the editor and the REPL, where edit a function and immediately run it in the REPL. Daniel. 0 0 Abe Schneider 10/2/15 Just to give the perspective of someone who has to both do research and implement algorithms in larger systems, Python has several niceties that I think have made it so successful: 1. It is a general purpose language. Unlike languages like Matlab, R, PERL, etc. it is not written for one particular task, but rather focuses on just making a good-enough language for everyone (good-enough because it will never be as good at what Matlab, R, or PERL do for those specific tasks). 2. It acknowledges and embraces its weak points. Python is slow. Instead of trying to make the language itself faster at the sake of losing generality (see 1), it makes it easy to switch to other languages. It's trivial to write a C/C++ extension for Python, which has boosted automated methods of code generation such as Theano, Numba, etc. The Pythonic way of doing things is to be explicit and worry about readability over speed. Optimization can always be done later or somewhere else (and usually this is true). The other extreme is Java, in which the designers purposefully made it difficult to use other people's libraries. 3. It provides the flexibility in the language to let users do what they want (I think it borrows this from C++), even if from the designer's standpoint you shouldn't. One of the strongest features of C++ and Python is operator overloading. My suspicion is that without operator overloading, Numpy wouldn't be the library it is, and without Numpy libraries such as: Scipy, Scikits.learn, and Matplotlib couldn't be expressive and powerful. Did Guido know that by providing operator overloading Numpy would exist? I'm guess no, but probably had a suspicion of what was possible because of the success of C++. 4. It has an open PEP process for adding new features. While Guido may be the benevolent dictator, he has provided a good process to include new features (e.g. Python 3.5 now has type hinting, which looks very similar to Julia's version). This allows Python to be a continually evolving language (which can sometimes stall with large committees), but stay focused on a single vision (which rarely happens with committees). It think Julia has many of these features, and that is why t's becoming popular, but maybe not all. One of the biggest hurdles I've hit Julia are in terms of flexibility and generalization (note: I realize that Julia is a growing language, and therefore some of these items may be included in future, so these are specifically of what I've experienced in v0.3). Specifically: 1. When writing the PEGParser library I've had issues with the flexibility of macros (see posts in the groups for details). Often the response I get back is that macros aren't meant to be used that way (which was often as result not from it being technically impossible to implement, but that it wasn't a feature worth supporting). Which is fine, but is definitely different from a Pythonic approach (e.g. see the crazy hacks done with Python annotations). I should point out there is another parser (https://github.com/andrewcooke/ParserCombinator.jl) that doesn't use macros and does essentially the same thing, so everything is possible in Julia. My main claim is that I think Julia macros are one of its largest selling points, and could be used to a ton of cool things (also the reason I wrote PEGParser), so it was somewhat of let down to have what appears to be arbitrary restrictions placed on them. 2. I think having assignment not be an operator is problematic from an extension perspective. For example, passing variables by value or reference could easily be dealt with by having a 'ref' object (e.g. foo(in, ref(out))), but to have a 'ref' class that works properly, you would need to be able to overload a set operator. 3. Inheriting from non-abstract classes is an important item for me (you can see multiple posts on the github page). In terms of building larger systems than just prototypes, this can be vital for creating some type of organization within your code. Yes, there are ways around this, but none that I saw that didn't violate DRY in some way. Note, this doesn't necessitate multiple inheritance, you can always do mix-ins like Scala. 4. Multiple inheritance, for the same basic reasons. All of this isn't to say that Julia *should* work in this way. It's just the things that I think made Python as popular as it is today (as per the question), and why it would be difficult for me to switch to Julia on a professional level. On Tuesday, September 29, 2015 at 5:30:19 AM UTC-4, Sisyphuss wrote: While waiting Julia 0.4 stabilizing, let's do some brainstorming. What's the reason of the Success of Python? If Julia had appeared 10 years earlier, will Python still have this success? 0 0 SVAKSHA 10/2/15 Re: [julia-users] Re: What's the reason of the Success of Python? On Fri, Oct 2, 2015 at 1:29 PM, Daniel Carrera wrote: > No, you didn't understand me. I don't have a bunch of repos with individual > libraries. I have my own program that is a big stack of functions that I use > to analyze the results of my simulations. I am constantly adding or > rewriting functions. A lot of my daily work consists of going back and forth > between the editor and the REPL, where edit a function and immediately run > it in the REPL. Ok, that explains it**. ** Yup, I would not know your workflow :) PS: https://github.com/sjkelly/SaveREPL.jl, if you want to save your REPL inputs for reference. I use unstable so this has stopped working for me but I assume some support for 0.4 /stable should exist. SVAKSHA ॥ http://about.me/svaksha ॥ 0 0 Daniel Carrera 10/3/15 Re: [julia-users] Re: What's the reason of the Success of Python? On 2 Oct 2015 17:33, "Abe Schneider" > > 3. Inheriting from non-abstract classes is an important item for me (you can see multiple posts on the github page). In terms of building larger systems than just prototypes, this can be vital for creating some type of organization within your code. I am confused. How would you inherit from Int32? What would that mean? How would that help you organize your code? > Yes, there are ways around this, but none that I saw that didn't violate DRY in some way. Note, this doesn't necessitate multiple inheritance, you can always do mix-ins like Scala. > > 4. Multiple inheritance, for the same basic reasons. Can you use union types? Daniel. 0 0 Milan Bouchet-Valat 10/3/15 Re: [julia-users] Re: What's the reason of the Success of Python? - show quoted text - Julia will likely support some kind of multiple inheritance in the relatively near future, at least under the form of traits. Actually, this is already used in Base, and can be used from any code. For the most recent discussion, see https://github.com/JuliaLang/julia/pull/13222 On the contrary, inheriting from concrete types is clearly a no-go given Julia's design. The compiler needs to be sure when you say a variable is an Int64, it will never contain anything else, or you're back to the performance of slow dynamic languages. But generic code should be written to accept abstract types, which should offer you the same flexibility in practice. If your issue is about the need to reimplement all methods of the original type in the new one, then this could be fixed via helper macros: https://github.com/JuliaLang/julia/issues/2248 Regards > Daniel. 0 0