I could’ve sworn we added a weaknesses/“why not Julia” section… somewhere… (to either the main website or the docs)… following a thread similar to this one to help set expectations. Maybe it’s still a PR? Anyone with better search-foo or memory on this one?
Yes, we run an annual survey: 2020 Julia User and Developer Survey
This is the second point I wanted to talk about, and thank you for mentioning it.
Most python users, as you said, don’t face the problem of execution speed because, for a wide range of use cases, the differences aren’t meaningful. although @lungben referred to JetBrains Python Developers Survey 2020 and mentioned that “higher runtime speed” is the 2nd item in users’ wishlist, we don’t have any information about their main problem with python. Besides, this problem would not occur for a wide range of users that doesn’t need higher speed (although all agree that having a higher speed is better than a lower one!). But Julia’s long initial start time problem occurs to anyone who starts using it. If it was a problem for a small group that needed a feature, it wasn’t a big deal.
Thank you, you are quite right about my confusion. I did read the posts you mentioned and am now slightly less confused. I still don’t know what the difference between AbstractVector{<:Real} and Vector{<:Real} is though. I had declared it as Vector{Real} which obviously didn’t work.
A major difference is scaling:
Run times scale with the size of the problem - doubling of the sample result in double run time.
Compile times, in contrast, are constant. They are always a few seconds (depending only on the software you are using), independent of the calculation sample size. Thus, they become insignificant for numerically challanging stuff. On the other hand, they are rather annoying if your calculations themselves are very quick.
64 bit
Probably that should be split in a new topic. But if you use AbstractVector your function will accept, for example, views, StaticArrays, and other array types which are not Vectors in the strict sense:
julia> f(x::Vector) = 1
f (generic function with 1 method)
julia> g(x::AbstractVector) = 1
g (generic function with 1 method)
julia> x = [1,2,3];
julia> f(@view x[1:2])
ERROR: MethodError: no method matching f(::SubArray{Int64,1,Array{Int64,1},Tuple{UnitRange{Int64}},true})
Closest candidates are:
f(::Array{T,1} where T) at REPL[1]:1
Stacktrace:
[1] top-level scope at REPL[3]:1
julia> g(@view x[1:2])
1
julia> using StaticArrays
julia> x = zeros(SVector{3,Float64});
julia> f(x)
ERROR: MethodError: no method matching f(::SArray{Tuple{3},Float64,1,3})
Closest candidates are:
f(::Array{T,1} where T) at REPL[1]:1
Stacktrace:
[1] top-level scope at REPL[8]:1
julia> g(x)
1
Concerning Real vs. <:Real I like my way to explain this, for obvious reasons.
Honestly, I feel like python gets too much credit here. It is easy to end up with python installs that have serious usability problems. I regularly have 5-20 time to first being able to type in ipython. I don’t really know why, because it varies from system to system and it’s not worth my time to debug a transient problem one system that isn’t a 100% show stopper (I work on many very similar, but slightly different computer systems running very similar, but slightly different pieces of equipment). I regularly (many times in the past few years) have issues where matplotlib is nearly unresponsive or hard freezes my terminal. At least some of the blame may fall on the somewhat opaque security settings my organization applies to our machines I always see these threads that take it as given that the python world has plotting and interactivity nailed, and it is not true. It’s mostly true, but I see exceptions on a regular basis.
Absolutely. Here’s how I think about this:
Once you get familiar with a tool, and you come to understand it’s deficiencies and find workarounds for those deficiences, they stop bothering you as much. You get used to them and sometimes even stop noticing them.
Later, if you try out a different tool that has a different set of tradeoffs, strengths and weaknesses, you’ll maybe notice the strengths, but you’ll also definitely notice the weaknesses. When you compare that new tool to the old tool, it becomes very difficult to make objective comparisons because you’ve trained yourself to not notice the problems with your old tool.
This effect is why a lot of Python programmers will brush off complaints about speed, expressiveness or composability and say “nah it’s not that big a deal”. It’s also why a lot of julia programmers (myself included) will just brush off complaints about compiler latency, documentation and such.
Python is the most popular language now, and that gives it a huge leverage relative to anything else. And there are efforts (numba, pypy, etc) that are solving many of the performance problems. So I do think that someone with a couple of years of python experience will more and more be comfortable where they are.
If numba and others were mature as they are now when I first started playing with Python, perhaps I would have dedicated more time to it and would not start learning Julia at all (it took me a while, even coming from Fortran). Now I don’t want to leave because simply I like the Julia syntax better, I like multiple-dispatch, the expressiveness, Revise is fantastic, distributing packages to students or everyone else is a piece of cake, and my programs turn out to be faster than what I was able to do with Fortran (which tells more about how crappy I was writing Fortran, perhaps), because writing, optimizing and testing programs in Julia for performance is much more fun. And I was able to learn a lot about computer programming in general by learning Julia.
In the long term it is likely that most of the problems of every language will be solved, languages will be highly inter-operable, and people will chose one or another for the syntax, paradigms, and expressiveness. Those are somewhat subjective, but Julia is in a good position there, in my opinion.
no it is not, if you are using linux or macos you have python beforehand so you do not need do anything to type in python. if you are using windows (like me) installing python in windows is very straightforward.
if you want to use scientific packages just install anaconda and that’s it, you do not need do anything else.
I am using matplotlib for 3 years and not, even one, time this not happened to me.
Python credit is not something we give it. If Python is so popular, it’s because of the efforts of so many people who have been working for it for thirty years.
Just a note in case there’s any confusion caused by this, ModelingToolkit.jl (and Symbolics.jl) are not reliable replacements for SymPy in every context. They are pretty young projects and can simplify far fewer expressions than SymPy (e.g. integration).
However, SymbolicUtils.jl, the library that those are built on at least at the present seems like a very good foundation for building up symbolic ecosystems, but it’ll take time. ModelingToolkit.jl is a great and poweful package that can do some things that SymPy can’t do, but part of the reason it’s docs are so domain specific is that it just doesn’t have the huge wealth of rules available to it that SymPy has and so won’t be able to simplify as many expressions. It’s main advantages are domain specific advantages.
Well, that is not completely true. Recently I spent a whole afternoon trying to use PyPy to run a code, because of bizarre issues with configuration files, conda environments, and I don’t know what else. I was quite impressed by how good was PyPy in accelerating the code, but the installation experience was horrible. Of course, for someone that already knows how to solve all the problems or configure things, none of those are actual problems. But that is what Mason said, when you know how to do stuff, the problems stop being problems.
Isn’t macOS shipping the old python 2.7 by default?
Official Python implementation is CPython and your problem with pypy, jython, brython, iron-python or micropython does not relate to the subject. this projects are not maintained very well like official CPython even a lot of the C packages, which is a huge share, can not be used in this implementations.
I always struggle more with getting Anaconda up than Julia. Julia is super-straightforward. You just prefer what you’re used to.
Of course it is.
yes
What you said here is the resistance or passiveness of a community against developing new features and enduring the problems they face as discussed before. If a deficiency bothers, it’s better to work on it, try to solve it and share it. This makes open source community powerful against closed source. Also a community includes beginners to experts, anyone can contribute, so if most of a community have this perspective to their problems, their product would someday be obsolete or outdated. What you said in general was not a productive feature for a community.
I’m not saying it’s a good thing or a bad thing. I’m saying it’s a psychological fact that as we get used to things that are uncomfortable, we cease to recognize them as uncomfortable.
I agree, What gives a programming language its character is its community, not its syntax or performance. All problems can be fixed with a healthy community, as Python did.
My problem was with conda, something about its environments, about my terminal not being configured to it. I felt like trying to use gfortran in Windows. I do not know if Conda is official or not.
But your answer just illustrates the same thing you somewhat implied in previous posts concerning the Julia manual, the Julia IDE, or others: that people that are comfortable with one thing tend to attribute the problems others experience to their fault, third-parties fault, etc. The thing is that you are used to one tool, that is fine, you will be more comfortable with that tool because you know how to deal with the weakness of that tool.
We could start and endless similar discussion on operating systems, text editors, linux distributions, etc.