I’ve often wished we had a Julia reading list that provided useful references for people wanting to learn about the big ideas involved in Julia.
For understanding mutable vs. immutable types, I found this very helpful: * http://cr.openjdk.java.net/~jrose/values/values-0.html It takes several reads to really understand, but it gets at the core issues. What it lacks is a broader CS-level exposition of how stack and heap allocated memory differ — that’s like a minimum background before that specific writeup will make sense. I’m not sure what a good read about parametric types would be. For the broader topic of invariants, the description of how Javascript’s v8 engine works without invariants is really useful: http://thibaultlaurens.github.io/javascript/2013/04/29/how-the-v8-engine-works/ For function specialization, I think Julia itself is the best place to have better docs. I think the docs already touch on the big idea: Julia writes a new function body for every tuple of input types. This could maybe be stated in a more didactic way. — John On Oct 26, 2014, at 2:54 AM, Andreas Lobinger <lobing...@gmail.com> wrote: > Yes, it helps a little bit. > The question was rather on what to read (what book to read) to be able to > follow discussions like Stefan's and John's discussion here. Obviously the > julia type system is a benefit for the compiler. > > On Wednesday, October 22, 2014 4:53:26 PM UTC+2, Iain Dunning wrote: > Do you feel like you are over-typing things? > > In function definitions, you only need types if you actually need to them to > pick a function to dispatch to. They don't make anything go faster, as a > specific version of a function will be compiled for every different set of > argument types you try calling it with. > > So, check out: > https://github.com/IainNZ/GraphLayout.jl/blob/master/src/spring.jl > for example. > layout_spring_adj{T}(adj_matrix::Array{T,2} > So it takes any array of element type T. For every time you call this with a > different element type, a different version of the function will be compiled. > So this fancy looking code: > if adj_matrix[i,j] != zero(eltype(adj_matrix)) > Simply gets turned into if adj_matrix[i,j] != 0.0 or 0 or False or .... and > so on, pretty magic! > > For Types, you should specify concrete types whenever you can, or use > parametric types if you can't. If you don't, and use say, Number, or leave it > blank, simple things like Float64s and Ints will be "boxed", so there will be > overhead whenever you use them and the compiler may struggle to infer that > some things are Float64s or Ints and not just Anys. > > Hope that helps somewhat. > > On Wednesday, October 22, 2014 7:28:12 AM UTC-4, Nils Gudat wrote: > Hi Andreas, > > Don't know if you've seen this already and whether this is helpful at all, > but I discovered this site once when I got confused by some TypeErrors, it > basically lays out the entire type tree of Julia. > > Best, > Nils > > On Wednesday, October 22, 2014 12:11:03 PM UTC+1, Andreas Lobinger wrote: > Hello, > > i'm now a julia user for some time, but still i have problems (comming from a > c, f77, matlab, python background) to understand the type system. Especially > when i try to integrate own code into packages (happened to Cairo + Compose, > pending for Winston) i seem to choose always a more complicated way (my > observation, code similar in py or c just looks shorter...) because somehow > things do not match. > > So. > > What to read to understand the julia approach to types and type interference? > > Wishing a happy day, > Andreas > >
