That’s one approach. Another one is to teach the compiler that errors are unlikely and have it automatically refactor the code so that the work that only happens in the error case is factored out into a separate (machine level) function. This is totally mechanical and doable, but no one has gotten around to it yet. This transformation is called “outlining” since it is the opposite of inlining.
Agree. I think this is one of the “advantages” that two language systems have: there’s an obvious barrier where the error checking happens. You don’t get random error messages from runtime errors in the implementation of Python numerical libraries because C just crashes so error checking has to happen at the entry points.
Keno did a bit of work towards moving a much better parser into the standard library, which allows fancy diagnostics like that. Stalled out though. Would be a great project for someone.
Of course this is true. One thing that occurs to me is something that came up in another thread of this sort that I thought was convincing - given the rate of julia adoption, maybe improving user-friendliness (whatever the definition of that is) actually isn’t a high priority. Yes, it would be a shame to lose users like you to that[^1], and I’m sure it would suck for you and your students personally to miss out on all of Julia’s nice toys like Flux and DiffEq and all the rest, but I have the impression that those toys are possible precisely because of the principled choices around things that strike you as a lack of user friendliness.
Sure, it’s possible some sort of wrapper, or GUI or, because it’s Julia and everything is possible, maybe even just a package, could make all of the changes that would make life easier for you, but unfortunately, it seems very likely that the people with the skill necessary to do that have other things that are also important to work on. Possibly (probably?) more important for the language. And for different selection reasons then the one you mentioned, they are unlikely to view your issue as a priority.
But my PhD is just in immunology, so what the hell do I know?
[1]: I’d like to echo this in the strongest possible terms:
Despite your impressions of the responses you’ve gotten here, people really are eager to help, and often do so with super human effort. When you get stuck, ask! It’s good role modeling for your students too.
I like a language that is consistent and predictable (Julia). Not one that is attempting to second-guess me and produces unexpected results just to return something (Matlab!).
I really don’t think anyone on this thread questioned your personal qualities.
Conversely, I believe that anyone on your position that is not just relaxing with what already he/she know but still pursue for teach students the latest innovations is admirable.
I just come from a presentation from an old professor of a very complex forest model.
It is implemented in Excel
I think there is probably a fair bit we could do in terms of IDE support for these scenarios.
Someone already mentioned linters, and I think the more things we teach them, the better. The linter that powers the VS Code extension is StaticLint.jl, if you have ideas of things we could detec, please open an issue! PRs obviously even more welcome.
The next step then is to offer fixes where the linter detected an issue. We started adding a couple of code actions in the latest version of the extension, and I think there is a lot of potential there to offer more for situations where the linter might detect an error that has a most likely fix.
I think in general we probably only want the linter and the code actions to react to outright erroneous situations, i.e. suggest a fix where the user typed some code that clearly won’t run. But we could probably also think about a “beginners” mode (via a setting in the extension), where both the linter and the code actions detect situations that are not technically wrong, but fall into some pattern where beginners often make mistakes.
Isn’t this exactly what has happened to method specificity rules as described in Jeff Bezanson “Whats bad about Julia” talk? Anyway, I’d for one would like to have a Juliette that is even more unforgiving than Julia is right now if it would lead to to a more robust language.
There a lot of things that are inherently interesting or useful, but would not be taught in an MBA class because it’s just not what MBA programs focus on. This includes most of programming and CS skills (beyond the basics), most of intermediate math, and for that matter almost all of graduate-level economics (because it involves a lot of math, and these days, programming).
The claim that you would not teach some computer language feature in an MBA class is probably the weakest argument against it.
The bottom line may be that Julia is a powerful language that requires some initial investment, and because of this it is not a good choice for users who only have a casual interest in programming. This is fine: those users were never its target audience. If you are teaching programming to such users, you and them are better served by using a language you both understand and feel comfortable with.
I saw what effect RStudio had on my ability to teach (and even handily use) R to a wide range of students, and I am sure something like that for Julia could have similar potential. It appears that some on here would doubt whether it would be worth it, but I don’t. I think that one day not too far in the future one will be able to describe a problem to a machine (even a mathematical problem) verbally and have it solve it. I just think that envisioning some movement in that direction is not wasted time.
[BTW, I have already requested that my teaching roster not include the MBA’s for now ]
You’re absolutely correct. A lot of the tools that make RStudio great have Julia corollaries that are being actively developed and I think there will be a time when this all comes together in very friendly way for complete beginners.
I don’t think the ideas you’re advocating for are going to meet a lot of resistance, but perhaps the expectations of how they are delivered. A complete reinvention of RStudio from the ground up is difficult to motivate without a dedicated developer team and some serious cash flow. But there’s no reason we can’t have something equally helpful in VSCode in the near future.
On a side note. This is the third thread I’ve personally participated in this last week on discourse that has become about an IDE for Julia at some point. I can’t speak for everyone, but if I come off as dismissive it’s not because I don’t care about what you’re saying. It’s because so much has already been said about this that it’s hard to squeeze anything more productive out of another conversation on it. The better error messages, IDE, introductory materials are all very important but that’s not news to anyone of us at this point.
In ecology students learning R first produces a lot of baggage. The short term gains are balanced by problems in the long term: the magic of things just working blocks people from actually understanding what is happening.
Lets not do that again. Simple, consistent syntax like dot broadcasting are the solution, not the problem. We just need to make it clearer how they work. But otherwise a solid easy to use IDE is a good thing.
@compleat can you clarify what you mean by RStudio? Do you mean in particular the IDE or do you also mean the tidyverse ecosystem? Like dplyr and ggplot.
I agree that MBA should be an audience that Julia appeals to, and I think DataFrames is doing a great job of working in that direction.
However I find it unlikely that an MBA student would need to work with arrays and matrices directly, rather, they would work almost exclusively with tabular data. There are existing tools in Julia that provide the necessary abstractions to avoid confusion.
I have been using Julia since 2012/2013, when you had to compile master to use it and when you had breaking changes every one or two weeks .
Being a MATLAB programmer, my eyes used to hurt when I saw those ::Int, and those <: AbstractNumber, etc. I actually considered quitting the language because it was too different from my status quo.
However, after a while (and after v0.7, when things got very stable), I get used to the language. I can assure you that the devs decisions were almost 100% coherent. When you learn the way Julia works, you realize how coherent it is today. It makes so much sense that often I have to do something that I have not done before, and I just happen to use the right function or the right syntax because it just makes sense. However, you must accept that it is a new language, not MATLAB.
If you say that MATLAB/Octave is easier to code than Julia, maybe I agree with you (but only for more simple programs). However, if you just get a little used to Julia, then you can get machine performance, which is almost impossible in MATLAB for some applications. This is a very nice trade-off, IMHO.
This kind of complain looks like the day I started to learn VIM. By that time I said: “How on Earth someone can remotely think to use such strange editor!” Today I just cannot use other text editor and I am very productive by learning how VIM works instead of wanting VIM to be like another editor.
The only point that I agree with you is that Julia needs a good IDE. Not to point your errors, just to make the user more comfortable, with a good plot system and access to the variables at the environment. However, we are talking about a language that has only 8 years or so (MATLAB has 36, R has 26, Python has 30). The future is very bright
I have always used Emacs, and think it is great. In fact, since Atom doesn’t work on any of my Ubuntu installations, I use Emacs/Emacs-shell as my IDE for Julia on there.
My Mac version works fine, and I have never had any problem at all with it.
With Ubuntu you have lots of choices, in terms of Display session Managers, etc. I chose MATE, which works for all my other applications, but (alas) not with ATOM.