Relevant video from juliacon on the type system core: <a href="https://www.youtube.com/watch?v=xUP3cSKb8sI" rel="nofollow">https://www.youtube.com/watch?v=xUP3cSKb8sI</a><p>Julia's type system is geared towards JIT compilation. Methods are compiled when they are first called. Then, of course, full type information for the arguments is available. That's quite enough for Matlab-style code with the occasional JITted method.
But Julia has one glaring disadvantage for everything beyond that: The return type of methods cannot be specified / enforced.<p>1) With "black box" methods (where the return type cannot be inferred as in this DataFrames article) the code becomes horribly slow. And you have to dig into the internal method representations to become aware of the type inference results.<p>2) It hurts the ability of Julia to produce binary executables. When the types are not 100% inferrable, the entire JIT infrastructure needs to be dragged along.<p>3) Types are not only an aid for the compiler, but also an aid for the programmer. With SIUnits [1] and method return types, Julia could even tell when the physics represented in the code is flawed!!<p>If Julia's type system were stronger, it could become a prime platform to develop Computer Algebra Systems (CAS). That could lead to a great unification of symbolic and numerical "computation platforms". However, current Julia is unable to represent the mathematics encoded in the type system of open source CAS like Axiom [2]. Also note the github issue on Julia and dependent typing [3].<p>Imho, there is still a great potential for the Julia type system without breaking existing code.<p>[1] <a href="https://github.com/Keno/SIUnits.jl" rel="nofollow">https://github.com/Keno/SIUnits.jl</a><p>[2] <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.27.2331&rep=rep1&type=pdf" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.27....</a><p>[3] <a href="https://github.com/JuliaLang/julia/issues/6113" rel="nofollow">https://github.com/JuliaLang/julia/issues/6113</a>
Is there no way to take advantage of the fact that most columns, most of the time, are filled with doubles? This is both the expected case and the thing we want to go faster. I don't know compiler design, which is why I ask.