Racket is a scheme derivative, actually it consists of several languages including some domain specific ones, that all are compatible with each other. It also has a _very_ nice C foreign function interface (much better than Haskells for example).
Thanks for the note. When I first heard "typed racket" I thought: "oh no, an obscure dialect of an already obscure language" and I was slightly disappointed, but now I understand that typed racket is not a derivative of racket, but rather racket is a domain of languages including typed languages. This makes it much more interesting to me. Thanks for the note.
When do you call a language "homoiconic" exactly? When it exposes its own AST (abstract syntax tree) structure? In that case, you can call any language homoiconic, whenever somebody builds a library that can transform a given AST back into executable code. I'm not sure if it is a very distinctive feature.
It's not about any "given" AST, it's about having a computable representation of any code. For example, if I pass you a higher order mathematical function that calculates the first derivative of another function (f), you can create an algorithm that integrates the function symbolically , thus obtaining (another) primitive (related to the original f by a constant). Note that I mean to symbolically calculate derivative…
So, to understand what you are saying, is it true that in LISP, you can write a function F that can take any function object G, and turn it into an equivalent AST of G?
I am a little weary of the hype around a language whose unique selling point is speed. Where else in Julia is there significant innovation versus Python? The latter seriously has it all when it comes to scientific computing, and if anybody is not already running vectorized numpy code, or trivially compiling critical for loops to c-like speed using Numba/Cython, then they're missing out on performance which has nothin…
You should read the paper, but Julia's also a really nicely designed language in general. It's hard to communicate how great multiple dispatch + a powerful type system is without trying it out (though, again, the paper does a good job), but yeah, it really helps you get a lot of generality as well as performance. When you use Cython, you immediately lose that generality. Then there's the really powerful metaprogrammi…
Compelling argument in your link about how performance for others allows for better libraries for everyone. I am still concerned that Julia does not go far enough in breaking the imperative programming mould, but I think it's disingenuous not to give it a serious try in more than trivial exercises. I have to say though that I have learned R, Python and Golang in the past 8 years and all of them are basically imperative (though R's vectorisation-everywhere is impressive - wish it was all just faster); I hope Julia will give me something dramatically more interesting. I say that because the LLVM has ushered in a period of radically easier language development, so we are likely to be spoiled for choice in the next 5 years. I hope Julia has done enough to put itself way out there in in terms of innovation to make the sizeable investment of time for myself and library developers, worthwhile. Altogether however I cannot be anything other than impressed with the dogged and convincing pitch that you and others are making for it, which somewhat lowers the risk of investing time in a dead end. And even if it doesn't work out all hunky, at least I'll know that Python will face serious competition, and that can only be good, even for Python.
You should read the paper, but Julia's also a really nicely designed language in general. It's hard to communicate how great multiple dispatch + a powerful type system is without trying it out (though, again, the paper does a good job), but yeah, it really helps you get a lot of generality as well as performance. When you use Cython, you immediately lose that generality. Then there's the really powerful metaprogrammi…
Compelling argument in your link about how performance for others allows for better libraries for everyone. I am still concerned that Julia does not go far enough in breaking the imperative programming mould, but I think it's disingenuous not to give it a serious try in more than trivial exercises. I have to say though that I have learned R, Python and Golang in the past 8 years and all of them are basically imperati…
How does the upcoming and even current numba+blaze power duo not allow library designers to easily write fast code?
Nice paper guys. Any plan to get something peer-reviewed? It would be useful for motivating biologists. Anyone interested in using Julia for bioinformatics is invited to contribute to, or follow the progress of, the BioJulia project: https://github.com/BioJulia/Bio.jl
Yes, we do want to submit it to a SIAM journal. It does seem that we are already getting interesting feedback here. The BioJulia team will probably write a paper on Julia in Biology and publish in a related journal, just like Miles Lubin and Iain are doing with JuMP in the OR community.
Yup, we'll definitely do one for BioJulia - but we've got a way to go before we reach that stage :)
It's not about any "given" AST, it's about having a computable representation of any code. For example, if I pass you a higher order mathematical function that calculates the first derivative of another function (f), you can create an algorithm that integrates the function symbolically , thus obtaining (another) primitive (related to the original f by a constant). Note that I mean to symbolically calculate derivative…
So, to understand what you are saying, is it true that in LISP, you can write a function F that can take any function object G, and turn it into an equivalent AST of G?
The spirit of your statement is true, but the precise formulation is incorrect. In LISPs, when you pass a function, you pass a list that defines the function. There is no special "turn into AST" step. Executable code is data, and you can create genuinely new executable code out of this data. There's no special "turn code into data" or "find the data corresponding to this code" step. Code just is data.
Compelling argument in your link about how performance for others allows for better libraries for everyone. I am still concerned that Julia does not go far enough in breaking the imperative programming mould, but I think it's disingenuous not to give it a serious try in more than trivial exercises. I have to say though that I have learned R, Python and Golang in the past 8 years and all of them are basically imperati…
How does the upcoming and even current numba+blaze power duo not allow library designers to easily write fast code?
Well that was the point of my original message. I am using numbapro and easily getting to c-speed with R-like vectorized convenience right now. It's why I question the "speed" argument as a non-argument when compared with Python. And I haven't even started using the cuda approach...
You allude to another point though: Python is not standing still. Python and its environment is a mighty high mountain for Julia to climb if it's not going to move the game forward significantly so that its big ecosystem disadvantage is compensated. Julia cannot just do incremental improvement - it doesn't have enough momentum to make that a winning strategy. It needs to leapfrog to take on Python.
I should add one more point though. The post mentions Matlab 15 times and Python only 7. It's possible this whole Julia effort will be successful with the Matlab crowd which, up to now, has been watching with horrified fascination from the sidelines as open source ate its lunch.
This sounds very similar to an approach called Lightweight Modular Staging (pioneered in Scala by the Oderski group - http://scala-lms.github.io/ and also in Lua - http://terralang.org/ ). While this is great for specializing numeric code based on runtime invariants like dimensionality, I think people are finally looking at using the idea in other domains - for example, runtime generation of DSL code on a per instant…
You mean like blaze in python?: http://blaze.pydata.org/docs/v_0_6_5/index.html
Blaze has a bit of a broader focus than what I was talking about, since blaze mostly offloads the actual computation to a particular backend. But a combination of blaze and a custom lowering of the computation into machine code using numba would be similar (although without the type safety for guaranteeing that certain optimizations are possible)
You mean like blaze in python?: http://blaze.pydata.org/docs/v_0_6_5/index.html
Blaze has a bit of a broader focus than what I was talking about, since blaze mostly offloads the actual computation to a particular backend. But a combination of blaze and a custom lowering of the computation into machine code using numba would be similar (although without the type safety for guaranteeing that certain optimizations are possible)
I believe that the numba compilation is planned for the coming year.
How does the upcoming and even current numba+blaze power duo not allow library designers to easily write fast code?
Well that was the point of my original message. I am using numbapro and easily getting to c-speed with R-like vectorized convenience right now. It's why I question the "speed" argument as a non-argument when compared with Python. And I haven't even started using the cuda approach... You allude to another point though: Python is not standing still. Python and its environment is a mighty high mountain for Julia to clim…
Nice. Do you find yourself having to contort code to work with numbapro?