201–210 of 258 posts
The author and I like Julia for nearly opposite reasons. (I write Julia for the language geek reasons. The power of homoiconicity is amazing for writing static analysis in the language you're analyzing.) It's really cool that Julia can appeal to people with nearly opposing priorities tho. :) I'm looking forward to giving the workshop at UChicago. It'll be my third time presenting an Intro to Julia workshop.
Will you be webcasting?
We have a Julia and iJulia app on https://koding.com . It's going to be used by Harvard & MIT students soon. It's public and everyone can try it by simple login to Koding. The best part is you can easily try it online, without installing anything. Here is an screenshot of how it's look like (iJulia and Julia inside Terminal): http://d.pr/i/MsZt The source of this app can be found here: https://github.com/gokmen/julia…
The reason to bet on Julia is disassembling a function? This is a standard feature in Common Lisp (ANSI standardized in 1994) CL-USER> (defun f(x) (* x x)) F CL-USER> (disassemble 'f) L0 (leaq (@ (:^ L0) (% rip)) (% fn)) ; [0] (cmpl ($ 8) (% nargs)) ; [7] (jne L33) ; [10] (pushq (% rbp)) ; [12] (movq (% rsp) (% rbp)) ; [13] (pushq (% arg_z)) ; [16] (movq (% arg_z) (% arg_y)) ; [17] (leaveq) ; [20] (jmpq (@ .SPBUILTIN…
So, this is going to be really slow inside a loop. Would the compiler be able to optimize it into a single multiply instruction if it could prove that the input had to contain integers?
Earlier quoted context omitted.
> That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpy's solution is as good as introducing two different operators The thing is that the multiplication operation for matrices is matrix multiplication, not elementwise multiplication. When you apply a polynomial like x^2 + y to matrices, you do not want to apply the polynomi…
If you are doing linear algebra, I agree. Yet linear algebra is not the only thing I want to do with numbers. I think most of the time I do use the elementwise operation, such as: x = linspace(0,10, 1000) y = (x Of course I can just use matrices and then I have the information at hand that I am doing linear algebra right now: x = matrix([[3, 0], [9, 5]]) Out[28]: matrix([[ 9, 0], [72, 25]]) x**2 + x I think this is n…
This sounds like premature-optimization to me. Maybe it's just me, but in the apps I write in dynamic languages, the bottleneck is rarely in the language. It's usually in some IO. EDIT: some sentence in the article gave me the impression he was using this for non-math-heavy stuff which is why I said this
Ok, good to see, but, what i can do with it that i can't with another language? -.-
I really don't like the anti-intellectual tone of the beginning. "The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…
1. A pretty significant amount of code is PHP serving broken HTML + Javascript, stuff which favours pragmatism over purity (to the degree that even some of the most pragmatic people hate it with a passion). These languages are popular because the authors focused on delivering results, not naval gazing.
2. When a language community starts talking up its the theoretical features with a passion, it's a red flag. Odds are, the documentation will be obtuse, and the community will bite noobs who don't know the theory. Even if they try to be nice to beginners, it's against their instincts to give simplified (if technically incorrect) answers. If your High School math teacher told you that "differentiation finds the slop of a graph, by finding f(x+e) / f(e) where e is really small", she was lying, but it's a good kind of lie.
A pedantic explanation will just confuse people, and stop most of them from understanding it well enough to learn how to appreciate the technicalities.