@Elrod thank you for your suggestions. PyPlot is what I am using now, and VegaLite looks nice and well documented.
However the problem is not that I am not happy with my current solutions. The problem ist that I am not happy with my way to these solitions. For example plotting:
For a simple XY line plot I copypasted a few lines from some example, using Plots.jl package, and it worked out of the box in Atom on my Windows computer at work and on the Mac at home. Great!
Now I needed a contour plot. Opened the Plots.jl manual, tried to understand the whole thing with backends and packages, didn’t find what I needed (though it is probably there), and went for PyPlot.jl. I don’t especially like Matplotlib but at least it’s familiar. I spent on the whole an evening of a half to get plotting to work, reading forums and trying different things. Now it works on my Mac, so I stay with it for plotting, and I am reluctant to even try it on Windows.
As a beginner I do not need a dosen or two of different graphics packages. I need just one, but one covering all basic and intermediate needs, completely documented and working out of the box with the language standard IDE.
Again, thanks all for your thoughts I will definitely get that book as well.
As I was taking an ‘exercise break’ I got an idea, which I don’t think would offend anyone’s sensibilities, and might be helpful (if a little crazy).
What if a ‘Lite’/‘Juliette’/‘Newbie’ mode could run the same as Julia, but focus on a different approach to error messages?
I think most of my (&others’?) frustrations can be boiled down to not being able to get things to run, and not having a clue about how to fix them. What if there were an AI-trainable debugger mode which would attempt to make suggestions in case of an error and would keep track of (willing) users’ errors, having them rate the usefulness of the suggestions, with a view towards such support getting better over time?
Hopefully, this wouldn’t deflect too much of developers’ time away from the ongoing development of Julia itself, and could help train an expert ‘assistant’?
Such a system could be trainable on the cloud or by having users (voluntarily) send periodic logs.
You can easily overwrite the default error messages, e.g. :
julia> Base.showerror(io::IO, ex::BoundsError) = print(io, "Don't try to access arrays out of bounds !! :(")
julia> [1,2][3]
ERROR: Don't try to access arrays out of bounds !! :(
Stacktrace:
[1] getindex(::Array{Int64,1}, ::Int64) at .\array.jl:744
[2] top-level scope at REPL[4]:1
This mean you could write a package with custom error messages, or hook up some logging. That’s one great thing about Julia, you can do things yourself instead of having to bother the devs.
A good specific thing about Julia development is that errors are not breaking changes, so they can be added as part of a new release. For example, this error is an example on where a error message can be improved. I’m still thinking (and looking for) on ways that a begginer can mess up something, where the error has an easy way to suggest a solution, and adding issues to the Julia github repository accordingly. In the future, as I become more fluent with the language, maybe do the PR myself
@compleat the Julia community is aware that in many ways, our error messages need to be improved. The problem is that experienced developers often don’t make the same mistakes as new users, so it can be hard to prioritize what to fix, and to know what advice would be useful. Any time you get an unclear write message, most of us would love it if you made a new discourse thread with a mwe that causes the error and what error message would be helpful. Sometimes it won’t be possible to improve for performance reasons, but probably 80% of the time, I think you’ll find that the next version of Julia will have a better error message for that problem.
I agree that the error messages are often hard to interpret, and I think it’s not just a matter of time & effort: It’s often because they come from somewhere deep in the machinery, which was left exposed precisely to make it possible to hook all sorts of strange and wonderful inventions onto it.
This is an interesting idea. And (as others said) it can be a package, which simply adds many more error messages. For example:
Base.:+(::AbstractMatrix, ::Number) = error("""Adding a number to a matrix is ill-defined,
perhaps you meant A .+ x (elementwise) or A + x*I (adding to the diagonal)""")
Base.exp(::AbstractMatrix) = error("""exp(::Matrix) means a matrix exponential in Julia,
you probably want exp.(M) for element-wise application""")
Teaching a course will probably give you a daily list of mistakes like this you can catch. And if your training wheels package forbids some advanced thing accidentally, that’s OK.
I hate Matlab’s implicit expansion with a passion that is almost unparalleled in my life. I’ve lost confidence in my Matlab codes and now I write my Matlab codes with assert on vector dimensions everywhere. While this is probably good practice, it destroys what I used to love about Matlab - dynamic typing to prototype algorithms. If I’m going to code a bunch of assert statements I might as well just write everything in Julia.
I used MATLAB a lot from 1990 to 2011 or so (still do, occasionally). One episode comes to mind: I tended to use tf to denote final time when solving ode:s. At one point, nothing worked, and there was no sane error message. After struggling with MATLAB for 2 days, it finally dawned on me: I had installed the Control Systems Toolbox, and tf created a transfer function object instead of a float.
My point: Julia is not alone in having error messages that are difficult to decipher. What I really miss (as a simple-minded, applied engineer), is a good, graphical debugger where I can click on code lines to set break points, etc. I know several of you developers work hard to provide improved debuggers in Juno, VS Code, etc.; to me, this is the most important feature missing (in addition to a good intro book to Julia similar to Higham’s MATLAB book).
Off-topic: wow! I had precisely this same problem. I was coding a ODE solver for my problem in MATLAB (by that time we did not have the amazing @ChrisRackauckas’s package…). I used tf and step. You have no idea how much time it took me to figure out both problems…
couple of items to continue to push this thread off topic
The production of understandable error messages is hardly specific to Julia. Not a reason not to stop trying to improve them, but if you want to feel good about Julia error messages, go run ghc on something with a type error on a curried function. Good look figuring out what’s going on. And this for a language that is, in fact, currying everything.
Also i have recently been in the position of having to deal with matlab after having used Julia for sometime. I can’t stand it…not even a little bit. There’s no way that the IDE makes up for the mess that is the matlab “language”. Cruftiness incarnate.
I think such a tool would be amazing! Whether or not it’s crazy or not, I’m hardly one to judge; it sounds pretty complicated to me, and hard to do well, but so does most of what goes on in this community.
I’ve been doing the opposite transition: learning Python as part of my teaching duties. I have been stunned by how many rough edges it has. Ever try to read the built-in documentation for list.reverse()? Matrix multiplication is a.dot(b)? Error messages routinely show the pointer in hexidecimal? Seriously?? The point being, it’s really easy to get used to the idiosyncracies of your first language and think that’s how it should be.
I don’t know if you’re experiencing the same issue that I did, but when I first started using Atom on Ubuntu, Atom would open in a 1 pixel by 1 pixel window… See this thread:
Julia is of course not perfect, but instead of assuming that you find it difficult because something is inherently broken with the language, you may want to consider the possibility that you are just learning a language that is fundamentally different from what you used before, and give it some time.
I think you have pinpointed the key reason why “training wheels” versions of Julia (or any language) don’t end up being implemented or maintained: new users just gain experience, and quickly transition from the “OMG Julia is weird we should make it behave like Matlab/R/Python/… otherwise it will dwindle into oblivion” mindset to “I can solve this complex problem in 20 lines, neat!”.
FWIW, I think that whenever we face a trade-off between how experienced users and newbies prefer something, we should focus on helping newbies becoming experienced users instead of padding the sharp corners of the languages with plastic foam.
To make this concrete, consider a stack trace: seeing it for the first time, it may be difficult to deal with an error message that tells you there is no method for * working on
when in fact the cause for this comes from duck typing 4 callers above the error site.
So we should provide tutorials and introductory material to understand stack traces and debug errors like this because they are a normal part of working with the language. This is an area where Julia is currently lacking, because the language is so young and the tooling is WIP. But we are getting there.
I think that is a very good way to look at it. Instead of “dumbing down” the language, one should make the users better at understanding errors and fixing them. Would be much more beneficial in the long run, for all parties.
According to Google Trends (as quoted in a recent Towards Data Science) the interest over time in Julia is as graphed below. It doesn’t look like exponential growth to me. I am not criticising Julia in any way, merely suggesting alternative supports to help overcome some of the ‘barriers to entry’.
