Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together.
> in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0].
This is mostly false.
First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust.
Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary.
If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').
why do you presume that's what the GP meant? your post is much more detailed than his
anyway, i know very well that julia has a great standard numerical library. it is a language catered to that community so it better have a rich standard library. my point is that functionality does not need to in the standard library in order to be useful or impactful. i don't think i need to prove my point but take numpy (or any other famous numerical package from the python ecosystem) as an example
>Second of all, CUDA.jl is a very weird thing to point to for your example
i work in machine learning so it is a very important package for me
> If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that
and CL is not. point is that you need to learn LLVM in order to dig deeper, if you so wish
Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together.
> in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0].
This is mostly false.
First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust.
Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary.
If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').