I’ve been reading all reference materials of Julia seen alot of scopes, … all things.
Would you please paint a code of mistake that begineer (especially python developers) do when writing simple like (variable, functions, let, module while, for, scoping, datatypes, dictionaries…etc)
Thank your explaining me. I hope i would learn fast forward from your basic mistakes you had done when learning julia and wanted me to aware.
Thank you.
This should be helpful: Noteworthy Differences from other Languages · The Julia Language
There are also quite a few “Julia for Python users” articles available on the net.
Not reading the whole manual, especially performance tips.
This book seems quite nice:
I 100% support what @Tamas_Papp suggested. Also I think it is good to make a distinction between: “common mistakes junior programmers make” and “common mistakes senior programmers make”.
I would say that the most common beginner problem (especially when working with data read in from external sources) is making sure that your collections have a right element type for your use case (if this is not clear what I mean by this please let me know and I can expand with some examples).
Related though not the same thing.
I wrote a blog post on things that seem at first like good ideas but actually are not
I will just slightly disagree with Tamas here. Although I think that reading the manual makes no harm, of course, I do not think that is a very good neither pleasant way to start learning programming, in Julia or otherwise. Up to the “Complex and Rational Numbers” section it is a nice introduction that can be followed by someone new to programming in general. After that it becomes (not always, of course) difficult to follow. It is a great source of information for referencing, but I do not believe that one can benefit a lot of reading that without having played with Julia for a while.
Of course the exception being if one is experienced in some other programming language that shares most of the Julia features (as C++, Lisp, Java…). In that case one can read the manual as being the translation guide from one language to the other, with its specificities which will be immediately clear to the experienced user.
Everyone has its own learning experience. But I would bet that most people, reading the manual or not, will have to make their own errors on variable scoping, assignment, type stability, before actually understanding what the manual was saying. At least this is how it has been for me.
Thank you @lmiq 
, I agree your point and i was also wanted get answer like that.
Thank you @Tamas_Papp , After finishing answers I will look to improve performance, but as begineer it codes there looks scared .
Thank you all guys.
I am learning from those links
One very common beginner error is being surprised when fill() creates an array in which every element is the same value. This can cause unexpected behavior when that value is some mutable object (like an Array), since modifying that value once modifies every entry in the fill result. For example: Initialization of array of arrays with `fill(ones(1),2,2)`: only one vector is created or fill(anArray,2) behaviour
At its heart, this is just about the fact that Julia does not implicitly copy things like C++ or Matlab would.
Yes, clearly I’ve been there already. I wander if anyone uses fill with arrays expecting that, or if fill should have a method specific to arrays or mutable values and copy in those cases. An array of arrays where the elements are references to the same array seems a very unlikely use case.
I remember things like sqrt(x::Float64) | x < 0 DomainError and the automatic: WTF, why? But, in fact, it was a good start to find out that type-stability is important in julia and why.
Confusing | with || and & with && is another common beginner mistake, I have a good sample of that within my students. And, to be honest, I still cannot understand were | and & can be useful.
(Also I do not understand what you would expect from that example, why it has to do with type-stability, and in which situation that syntax may appear).
How many people do you honestly think read all 1335 pages of the manual?
To answer the original question: one mistake I’ve seen new users make is to copy & paste awkward vectorized code from Matlab into Julia. Julia is not afraid of loops.
Here’s a few from my long list of annoyances/notes/tips I keep track of, as I’m a Julia beginner compared to my usual Python and C++ development:
: includes the last index in Julia, so a[0:4] in Python would be a[1:4] in Julia. You get used to it, but I madeplenty of mistakes as the zero-based indexing I’m from Python/C++ needs to be filtered +/-1 to apply to Julia.* instead of +' for string literals, as that produces a character and not a string. Again, this one happens all the time, as in Python I only use ' quotes as it saves an extra keystroke compared to "return in functions (as there is no warning when you do), leading to the last expression being returned. In Python not using return always causes None to be returnedinclude() statement end up in the stack trace as something like include at ./Base.jl:368 [inlined]. It takes some time to learn to filter that.Bool show 0 and 1 elements values when printed instead of true and false , leading you to believe that the values are of type integerfor (key, value) in array (i.e. parentheses are needed)Float32 literals are written 2.0f0 and not 2.0fimport re; help(re))There’s also plenty I like about Julia, e.g.
One of the biggest hurdles I personally had (and still have) when learning Julia initially is the documentation system at https://docs.julialang.org. Although it is very extensive and contains quite a few examples the search function is almost useless as it doesn’t provide context of search hits, but only a (usually very short and general) section title and the type of page. So you can’t really judge what hit to check out, and there’s usually many hits when searching for basic concepts when learning. Plus the navigation/layout using the scrolling outline pane on the left is a pain (it contains too much detail, when following links you don’t really see what’s going on and the scrolling frame doesn’t help). I think the layout, navigation and search (and therefore overall accessibility of the docs) could be greatly improved if it would use Material for MkDocs. This for me is turning into the gold standard for technical documentation, as it uses a clean and functional layout, uses modern web technology to provide interactivity and layout and provides excellent client-side search. It also looks gorgeous.
I could go on, but wanted to end on a more positive note 
. One of the best things about learning Julia is this forum, I got plenty of useful (and quick) responses to questions I had!
Nice list. Thanks.
This drives me crazy in python. It so so unnatural! (and my background is mostly on Fortran).
This one I don’t get. What is the alternative? To have everything of each module in a single file? Sounds inconvenient (or at least inflexible).
Uhm. Either you want to return something and you assign that to a variable in the function call (you mean forget return in these cases? Never happened to me 
), or the return value is not assigned, and I do not see any reason for concern.
Functional programming is, imo, more natural than OO. For someone new to programming it is easier. Of course, with backgrounds that is other story.
Here I think that the manual fails a little bit. The inner variant is for very specific cases.* I still never used one. But from reading the manual for the first time it is not obvious that outer constructors are by far the most common ones, and particularly people used to OO programming tend to start writing inner ones and get confused.
*This is clearly written in the manual, but it is of those concepts that I only really understood after a while making my own mistakes. The section on constructors is too technical.
In Python, every .py file is a module and every subdirectory a package (just a group of modules, not package in Julia sense).
In Python, modules are used more extensively than in Julia (probably due to the lack of multiple dispatch), therefore I do not see this as problematic.
The Julia include way is also fine for Julia imho because Julia modules are often larger than in Python and therefore it often makes sense to split them to multiple source files.
Oops, I shouldn’t have quote the whole expression. It is not all julia code, I meant sqrt(x) such that x is a float and non positive. Sorry
Je, I imagined all the time the mirror answer in a python forum
What I found really confusing at first is that Vector{Real} is not an appropriate supertype for dispatching on Vector{Float64} and Vector{Int}, and you need Vector{<:Real} instead.
Or better yet, don’t constrain to Vector and use AbstractVector{<:Real}.
Or better yet, don’t constrain at all if not really necessary and just see if the generic code can handle what you throw at it.
I also got very frustrated in the beginning when I used Julia in Jupyter and often created specific methods, which I later deleted and replaced with less specific ones. But the earlier ones were still active and couldn’t be removed, which caused all sorts of weird bugs. Then I had to restart Julia everytime and wait for compilation again. I almost dropped the language due to that because I thought how can it be so hostile to minor mistakes and iterative development. Now there are better workflow tools in most cases.
Obviously splitting up large source files into smaller logical pieces is a good thing. My issue with the Julia way compared to Python is that included source files do not (in general) explicitly contain all of their dependencies, as Python modules do, as the code in a Julia source file included in a top-level module file depends on the files included before it. While Python modules can always be tested standalone by using an if __name__ == '__main__' block included Julia files usually cannot, as its dependencies are frequently declared outside of the file. It also makes it a bit harder to figure out how a module is organized as you need to search where definitions in an included file making up a module come from.