Live data from Hacker News

Why I'm Betting On Julia

evanmiller.org

131–140 of 258 posts

Re: Why I'm Betting On Julia

#131

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…

This is also possible to a degree in Python, though you only get the bytecode:

    >>> def f(x):
    ...     return x * x
    ...
    >>> import dis
    >>> print dis.dis(f)
      2           0 LOAD_FAST                0 (x)
                  3 LOAD_FAST                0 (x)
                  6 BINARY_MULTIPLY
                  7 RETURN_VALUE

Re: Why I'm Betting On Julia

#132
post #96

mini ASK HN: would there be any interest in supporting Julia in Visual Studio? (as a free/oss plugin). i lead the Python Tools for Visual Studio project at msft and would be curious if there is interest. as a side note, if you do you use Python & require Python/C++ debugging, PTVS now supports it: http://www.youtube.com/watch?v=wvJaKQ94lBY#t=10

Are you using the IPython protocol for communication with python? If so, extending it to julia should be fairly straight forward.

we are for the integrated IPython REPL. but my question was more in terms of intellisense, debugging, profiling, mixed julia/C++ debugging, etc. ie, a fully integrated experience in VS.

Re: Why I'm Betting On Julia

#133
post #97

I don't really see the need for the author to make himself into a "cowboy" coder and point out how they ignore all those valuable insights and enlightenments of programmers. Julia is a kind-of-fine language that is designed to appeal Matlab users first of all by its syntactical looks. Just like Javascript was designed to appeal to C and Java users by imitating their look. Under the hood, Julia is quite a smart develo…

> "The part where Julia kicks in now is the point that Matlab has a lot of market ground, especially with engineers who are not extraordinarily passionate about programing. For some people the burden of learning another syntax is just too big, they are not full time programmers but spend their time more with acquiring data and using the results. I really hope that some of them who are not willing to switch to scientific python can agree on switching to Julia."

As I see it, this will be Julia's main market. Younger engineers (read: "non-CS engineering students", i.e. electrical, mechanical, civil, etc) may encounter Python in college and become proficient in it, but because of historical reasons most of their assignments require some combination of Matlab, C, or Fortran. Even in group projects where the students have more independence with their choice of tools, if only one person in the group knows Python, the group will probably default to one of the common tools. When time is a scarce resource and time spent learning Python doesn't show much promise of improving your class performance, most students will neglect it.

Julia, at first glance, looks very familiar to a practicing engineer or scientist who is experienced with Matlab or Octave. It's the sort of thing that you could teach yourself in a weekend, and teach others at work if need be. Not necessarily the low level cleverness of the language or some of the more advanced uses of it, but enough to Get Stuff Done(TM). And that's what matters to most technical types without a background in CS. They will appreciate elegance and safety when they see it, but they're not going to decide what tools to use based on those factors.

Re: Why I'm Betting On Julia

#134

Earlier quoted context omitted.

Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R. Julia is…

To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awk…

Check out the Julia pycall library. It allows arbitrary python calls from inside Julia with nice autogenerated bindings from python objects to Julia types.

Re: Why I'm Betting On Julia

#135
post #39
post #31

Earlier quoted context omitted.

Really? My impression is that it's largely correctness.

But that allows for smarter optimizations.

Of course it does, and I never said it didn't. I just said that my impression is that the primary motivation of language people is correctness. However, I have published several in the area of software verification, so perhaps I am biased.

Re: Why I'm Betting On Julia

#136
post #97

I don't really see the need for the author to make himself into a "cowboy" coder and point out how they ignore all those valuable insights and enlightenments of programmers. Julia is a kind-of-fine language that is designed to appeal Matlab users first of all by its syntactical looks. Just like Javascript was designed to appeal to C and Java users by imitating their look. Under the hood, Julia is quite a smart develo…

What still amazes me: While working in an ipython notebook (http://ipython.org/notebook.html) on some numerical calculations, I can just pull up Sympy (http://sympy.org) and perform some symbolic computations (Fourier transforming some function analytically or taking the derivative of some other, etc.).

You can certainly do it with Matlab (provided you have purchased the symbolic toolbox of course).

Oh, and have I told you about how Scipy can replace R for really cool statistical analyses?

Sure, it can for some things, but why?

My thing with Python is that it kinda loses to Matlab for non-statistical work (except perhaps for select fields, like network analysis or language processing), and to R/SAS/Stata (depending on type of job and personal preference) for statistical stuff. Of course all of these (other than R) are proprietary and not cheap, but most universities have all of them anyway, and businesses just buy what they need.

btw: did you first learn Matlab, or Python? In my experience, there is a tendency for people who start with Matlab to dislike Python, and for people who start with Python to dislike Matlab :) Probably has something to do with some basic things being just so slightly different, and therefore bothersome.

Also, the Matlab IDE these days is actually quite decent -- does Python have something similar?

Re: Why I'm Betting On Julia

#137

Earlier quoted context omitted.

I tend to agree with you about tools. I have yet to meet a language feature that's more important than library availability, profiling, autocompletion, documentation, debugging, etc. Then again, I don't face the script/C/CUDA choice everyday (most of his detractors on this thread don't either, I'd be willing to bet) so his circumstances are probably different enough to justify a different priority list. His argument…

> I've never met a FFI I didn't come to loathe I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer programming improvement isn't strictly a programming language at all, but rather something that rethinks the linker, manages execution, and facilitates interfaces between larger blocks of code (maybe in multiple languages).

COM was actually not a bad model. Sadly the closest thing is HTTP and JSON right now.

Re: Why I'm Betting On Julia

#138
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.kdapp

I'm happy to answer any questions :)

Re: Why I'm Betting On Julia

#139

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…

This is also possible to a degree in Python, though you only get the bytecode: >>> def f(x): ... return x * x ... >>> import dis >>> print dis.dis(f) 2 0 LOAD_FAST 0 (x) 3 LOAD_FAST 0 (x) 6 BINARY_MULTIPLY 7 RETURN_VALUE

And the bytecode is just calling polymorphic methods. All the real work is done in the object implementations of type(x). I was very bummed years ago to realize how shallow the bytecode representation in Python is. There is no sub-terpreter, just C.

Re: Why I'm Betting On Julia

#140
the interesting thing is that what excites me about julia is that it is clearly a scientific computing language designed by people who are language geeks. the feature set seems very clean and well-thought-out to me.
Post reply on HN