Idea Julia Lite or 'Juliette'?

You say ‘Most of the users I know felt quite natural [using Julia]…’

It doesn’t take a PhD in Statistics (which I happen to have) to realise that this is a strongly biased sample. The users who experienced difficulties (maybe some of the same ones I had experienced) just stopped using it so you don’t hear from them. Instead of taking that course (giving up), I am trying to be constructive to see if somehow julia could be made to work for me, because I think it has potential that I don’t want to see wasted. However, I find myself under attack on here, unfortunately. What I am asking is that someone please listen. I say user-friendliness is a big issue with Julia, and I think I have the experience to know whereof I speak.

5 Likes

I think there’s a big difference between being under attack and the mere fact that people disagree with you because many of the points have previously been considered, and decided against. Several people have described it in detail and linked the relevant discussions on github.

I took a peak at your post history, and unless you’re also on slack and I don’t see your questions there, then I think you really should just ask more questions on here when you’re in doubt! Post some sane code in a MWE-way, and you very often get a very good answer very fast.

9 Likes

Perhaps, but possibly only an IDE that detects the subtle bugs that are costing me (and no doubt others) so much time.

Might it be possible that this is a case where having lots of experience ends up being an obstacle? Myself, when I come up with a workflow that I like, I stick to it and hate having to change it – for example, I’m still using openbox as my windows manager (no DE) after 15 years or so, and I’ll probably never change it.

Maybe try putting your mind in a “clean slate” mode when programming in Julia? Don’t try to make it fit a model it’s not designed for.

4 Likes

Personally I really like the errors produced by Julia compared to other languages. That being said, they are definitely not perfect. I think that’s actively being worked on and if you have clear suggestions they’re welcome.

2 Likes

For what it’s worth, all of the features you mentioned are completely optional.

Broadcasting is a nice convenience, but if it seems too foreign, don’t worry about it. for loops work just fine.

If performance isn’t a driving issue for you, don’t worry about types yet. Just use them for dispatch when you need them and keep everything generic otherwise.

As for immutability, if you want something like a MATLAB struct that can have fields appended after creation, consider a Dict . If you just want the field values to be mutable, there are mutable struct s.

3 Likes

@compleat may I ask what you find appealing about Julia? Based on your posts so far I am baffled that you are still sticking with it.

1 Like

It seems to have many of the combined capabilities of MATLAB, numpy, and R, with the performance of C++, and has syntax quite like MATLAB (which was based on its predecessor, LINPAK) which I have been comfortable for many years. I think Flux is an intriguing approach to Machine Learning and is close to being really good. I also like that Julia has an impressive suite of optimisers, not all of which I have tried yet. So in summary, I think that, in the main, it is where numerical computing needs to go, but I think user-friendliness has not been sufficiently prioritised to date, and I get frustrated at that.

2 Likes

But if you use 10-50x as long to write code compared to Matlab, and you’re not interested in many or most of the core features, why not just write C or Fortran?

In fact, if you remove the features you suggest, I’m sure Matlab would beat Julia on performance.

I’m sticking with Julia largely because of the promise of it.

2 Likes

Maybe there’s another way to come at this discussion. What would you like to keep in Julia Lite? What would be the difference compared to Matlab?

The latest innovation from the world community in machine learning and applied statistical methods appear in R and python, and for many reasons this cannot happen in MATLAB. I like to be able to use these packages in Julia and know that innovation will be quicker and the community more robust. Also, as I mentioned, I am quite intrigued by Flux (even though it has suffered some issues in its latest upgrade). The support of DataFrames in Julia is much better than MATLAB, and the choice of optimisers much more broad. Code also runs faster (usually). The writing of functions is cleaner.

Well, that seems to be mostly about being free and open source, not fundamentally about language design. Matlab also has nice ‘table’ support now. It should also be competitive (at least) on performance, if you don’t want to care about (im)mutability and type stability.

But as I said I think only in Julia are things like tracking in Flux (or what is replacing it when they get that working) are possible. Having gradients and hessians, etc. computed automatically. That is elegant. I think something like that exists in optimisation as well in Julia which I haven’t explored much yet.

But I’m skeptical that those features can remain if you ‘gut’ the language of other essential features.

I am sure Julia could be much more ‘forgiving’ than it is and still have all that capability, but I sense an avoidance of ‘forgiveness’ is an integral part of the way Julia is. I just wondered whether a more forgiving ‘Wrapper’ might be possible.

A few year ago (before I was hired), my boss posted an internship looking for statistics graduate students using Julia.
Apparently no one (good?) applied, while they get on the order of a hundred applicants for their R and SAS postings.

The more coworkers who use Julia, the more valuable my work becomes internally.

Teachers, particularly at the graduate level, have an inordinate influence on what languages people are learning. Personally, I would like @compleat to be won over.

I am surprised by the combination of the amount of time you’ve apparently spent learning Julia, yet how much slower it is for you to write code in Julia.
Julia strikes me as simple, because it follows just a few rules that it applies consistently.

For example,

I would also be very unhappy with behavior like this:

A = Array{Int}(undef, 13, 34);
B = A;
A === B
# true
fill!(A, 0)
A === B
# true
fill!(A, 0.0) # or A .= 0.0
A === B # A is now a different array, because the filled value had a different type
# false
typeof(A)
# Array{Float64,2}

which it sounded like what you want?
Why should the assigned value win over the original array type? Do you want the assigned value to “win”, or would you prefer a call to promote_type?

My impression is that you would like the Julia wrapper to be much less predictable than Julia (require much deeper decision trees to figure out what a piece of code will do), but to follow a pattern of behavior more similar to your experience with certain past languages you have used.

Other people, who have used different languages, may have different preferences for their wrapper.

I’ve heard MATLAB does something like this (I don’t know MATLAB, so this may be inaccurate):

A = zeros(4, 5);
A[4, 6] = 2
size(A)
# (4, 6)

Isn’t this also really confusing?
It would make finding off-by-1 errors very difficult.
IMO, when something is ambiguous, it’s much nicer for it to throw an error and ask you to be clear than pick something, and wish you luck in tracking down the bug if it picked differently from how you expected.
And if it “only works when it’s not ambiguous”, then someone who didn’t realize what they just wrote is ambiguous will again suddenly be confused when their code does not work.
Versus telling people “add dots to make an operation elementwise”, which is a simple rule that should avoid any mystery in the future. And (in my opinion) is far better at “doing what I mean” than the behavior you get in R.

Similarly, writing to an Array will not change the Array, just its contents.

6 Likes

I fully agree with @Elrod here, I would greatly dislike such proposed behaviour. However, I do think that @compleat is right that our error messages can often be cryptic. I think experienced julia users are pretty used to our error messages by now and know how to get the information we want out of them, but a persistent theme in julia complaints comes from people frustrated by our error messages, so it’s something we should try to improve.

Perhaps we’re all getting a little distracted by some of @compleat’s suggestions, when there is a real, legitimate gripe here about the state of error messages.

3 Likes

Error messages definitely need a lot of work. There’s an unfortunate conflict between performance and good error messages since errors that capture a lot of useful information can cause a function that is otherwise very simple to become too complex to inline, for example, and in particular requires heap allocation in a function that would otherwise be non-allocations, which can prevent certain optimizations and slow things down a lot. Other things are just a matter of doing the work to improve the error messages. It’s always appreciated to file issues about error messages that should be improved.

13 Likes

I don’t think we necessarily need to capture more information in order to improve our error messages. Experienced julia users seem to have no trouble getting what they need out of error messages / stacktraces in most circumstances, it’s not unreasonable to think we can make it smoother for new users to reach that point.

I suspect that a lot of gripes about error messages, are really more about the user not knowing how to use the stack trace as a debugging tool. This could be alleviated if we were to present the information in a more palatable way.

I think one of the worst offenders for producing cryptic error messages is that duck typing often causes the top of the stack-trace to be concerned with some random function that user has never heard of in a module the user doesn’t know about. Perhaps if we had better visual markers for when a stack trace crosses over into another module, especially when it leaves Main, that could help.

Another big one is syntax errors. Since we have the offending string in a syntax error, maybe it would help if we showed it to the user and tried to identify the location of the error, i.e.

julia> x = 1; y = 2;

julia> (1 + x^2) y
ERROR: syntax: extra token "y" after end of expression
Stacktrace:
 [1] top-level scope at REPL[5]:0

Here, perhaps a better error message would look something like

julia> (1 + x^2) y
ERROR: syntax: extra token "y" after end of expression
Parsed string: "(1 + x^2) y"
                         ↑ Problem here
Stacktrace:
 [1] top-level scope at REPL[5]:0
4 Likes