I’m new to Julia, an old engineer who’s been using MATLAB and Python for decades.
Why do we need something new? I’m really enjoying learning Julia. I’m finding this language has a steep learning curve. It is making me think and giving me a fresh perspective on the old tools.
Here are some of my musings about how different it is.
Hm, there seems to be almost no content in the notebook or am I missing something?
Also, the first point
There is a division operator - ÷ - that is the same as “/”.
is not correct.
Looking at the help:
help?> ÷
"÷" can be typed by \div<tab>
search: ÷ .÷
div(x, y)
÷(x, y)
The quotient from Euclidean division. Computes x/y, truncated to an integer.
Examples
≡≡≡≡≡≡≡≡≡≡
julia> 9 ÷ 4
2
julia> -5 ÷ 3
-1
@kristoffer.carlsson no you are not missing anything. I have a lot of notes about other stuff and as I google and read the docs, I keep having “aha” moments. I thought it would be good to start documenting some of these and share them with others. This way, I have a record of what it was like as I came at the language from a fresh perspective. And also, I get feedback - valuable feedback such as from you! - from more experienced folks to point me in the right direction. So THANK YOU for your response!!!
I wasn’t sure about ÷ since it is not listed in the docs (I am referring to this page - not sure if a more recent update exists).
That’s actually a flaw in the documentation! Good catch!
The binary operator ÷ (i.e. div(x,y), integer or Euclidean division).
It should be in the table, the same as % (the equivalent to rem) is.
You should make a github issue (or, if you feel up to it, you could make it your first PR for Julia)
It is also missing from the precedence table.
If you look carefully, it is present in the list of updating operators, i.e. ÷=
Thanks @ScottPJones. I’ll make an issue.
Note, I updated my “blog” on github saying that they are indeed different - thanks again @kristoffer.carlsson.
I actually found the opposite, but maybe that’s because of my background with Scheme & CLU (almost 4 decades ago), and C/C++ since school.
There’s been some tension in the design, IMO, because some of the things were taken from C, the operators, string literals (with the addition of $ for interpolation), and printf style formatting, while others were taken more from Python or Matlab.
The stuff based on C sometimes feels both familiar and antiquated to me (for example, Swift has a cleaner string literal syntax, that doesn’t use up another common character, $, for interpolation, and doesn’t have the strange \uXXXX vs. \UXXXXXXXX Unicode escapes).
One of the great things about Julia is that you don’t have to live with that if you don’t like it, it’s not hard to add new string literal formats (which I did first in my StringUtils.jl package, and then updated it to StringLiterals.jl`)
In your PR, there’s still a place that was missed, in the precendence table
I also I think it would be better to simply do what it does with %, and say "equivalent to div(x,y)".
Nice that you’ve got your first PR!
I agree with him.
Julia started very simple.
Yet the current syntax seems to be overly smart.
If you come from MATLAB it really looks complicated.
I come from MATLAB and find it straightforward. I find Julia is as simple as MATLAB if I only use it to do things that are easy in MATLAB. If I want to do more, faster, and I do, Julia is the way to go …
What part of the syntax do you think has become harder to understand?
(I think it’s good to learn contrary views, can learn something)
For instance I encountered this:
I think it’s me but this frighten me :-).
I understand simple types (Int, Float, Double) and structures (Array, Struct, etc…).
Then I see this…
Well, A*x*B seems like very simple and straightforward syntax, and the same as in Matlab, BTW.
Or are you objecting to advanced use of types? In that case, you can stick with the simple types. Also, you can make weird and complex classes and hierarchies in Matlab too.
Hi sirtom67,
I read in your github notebook that you wonder how to get the ÷ operator in the vi text editor.
You can get it in vi (and also in vim and neovim) through julia-vim typing “\div” followed by “tab”
The whole type system is something which I enjoy to learn, but I have some fears, that it can be quite complex but, on the other hand, it seems to be vital to create good (in many senses) julia code.
So, this is my concern, while I am digging deeper into julia. Still I am very delighted about the language. The first time, after many languages I used and tried, I am not thinking, ok, just another flavor of the same (don’t pick at this last statement = all the same, its just for brevity).
I had almost been about to ask before whether it was the new where syntax that you felt it had gotten more complex.
Once you understand it, it’s actually a lot more consistent and easier to understand than the old:
function foo{type_variable_names}(....parameters with type_variables...)...
IMO, and definitely a lot more powerful.
As @DNF said, it really only comes up when you are doing advanced things with types, and the nice thing with Julia is that most times, you can just leave off the types entirely, and let Julia infer them.
All the where stuff is only needed if you are writing functions where you need to specialize methods based on the type, and that, only for advanced cases.
Usually something like:
function myfunc(val::Number)
# Scalar numeric operation
end
function myfunc(val::AbstractVector)
# Vector operation
end
is about all you’d need until you get to fairly advanced cases.
Well, it is only reasonable that most of my fear is based on old habits compared to something new.
Is there a simple guide about this Type System?
I’d love to learn it and utilize it properly.
In general there is a tension between those who create the language and have deep understanding on how things work to the users of the drivers.
I read once that car engineering is harder than spacecraft engineering mainly because of the use cases and the users.
In spacecraft the use case is well defined and the users are highly competent and well trained.
While in cars you can never know what the user will try doing with it and also the dynamic range of the user capabilities is amazing and still the car must perform reasonably in any case.
Hence its engineering is challenging yet must be kept simple.
I can see this trend in many languages.
I don’t have enough knowledge in Julia to say its balance is too shifted towards those designed it or are amazingly capable, but it is just something to keep in mind.
https://docs.julialang.org/en/stable/manual/types/ is a good start.
This explanation is holding up pretty well after 5 years.
Regarding your notes: while surface syntax has its importance, it is arguably not the most interesting or novel thing about Julia. If I had to pick one key feature that defines the language, it would be efficient multiple dispatch on parametric types. This is not to say that everything else is unimportant, but this is the most novel part.
Coming from an engineer, “steep learning curve” may be used in the sense of “accumulating knowledge at a rapid pace”.
Although I’m an engineer myself, I’d never heard it used with that (opposite) meaning. Thanks for the info! (I do like to learn something new every day!)
Unlike many of the curves shown in the article you pointed to, that are steep and then flatten out, one thing I love about Julia is that, while I felt it had a very fast learning curve at the beginning (I was making PRs right and left [that got accepted!], just a few weeks after learning the language, and I feel that’s true for a lot of people, it’s a very accessible language), I’m still learning interesting and cool things (as are all of us, even Jeff, I think!) about the possibilities of Julia, 3 years, 1 month, and 2 weeks later! 
(Julia’s so bright, I need to wear shades!)
Here’s the thing: it’s waaaaaay easier to think about all that stuff than classes and inheritance in OOP. It’s just much more intuitive.
Julia has many wonderful attributes as I’m sure you are now discovering. For me the most important aspect of Julia is multiple dispatch as a core paradigm of the language. This is the thing that makes me never want to use any other language ever again. I now view object-oriented programming as a broken concept, and this is coming from someone who’s primary language was C++ for about 8 years and, in that time, couldn’t conceive of writing any complex code without OOP.