Julia: A fresh approach to numerical computing • Hacker News Board

Re: Julia: A fresh approach to numerical computing

#81

Post by lqdc13 » Sat, Nov 08, 2014, 5:44 PM UTC

wbhart wrote: post #47

monochr wrote: post #4

What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn'…

This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can…

Dictionary performance is still slow from what I can't tell. Like 2x slower than Python last time I checked.

https://groups.google.com/forum/#!topic/julia-users/hxfR70Ro...

I also find the dataframe library to be much harder to use/not much faster than pandas.

Great community though.

Re: Julia: A fresh approach to numerical computing

#82

Post by infinite8s » Sat, Nov 08, 2014, 5:46 PM UTC

one-more-minute wrote: post #26

wbhart wrote: post #20

I've been playing around with the Cxx library (currently only works with a source build of bleeding edge Julia) https://github.com/Keno/Cxx.jl It allows you to basically embed ordinary C++ code in Julia code, to interface with C++ libraries at runtime, and to slurp in entire .h files unmodified. (It also in theory allows a C++ REPL mode to be written, though such a thing does not exist for Julia yet.) It makes very c…

For reference, a staged function is something sorta similar to a macro, except it lets you take advantage of Julia's inferred type info. Contrived (and wholly redundant) example: stagedfunction foo(x) if x == Int :(2x) else :x end end y = 1 foo(y) == 2 y = 1. foo(y) == 1.0 Again, just like a macro, except that before `x` is quoted you work with the type of y instead of the symbol `y`. This means you can do even more…

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 instantiation basis. Imagine taking a high level SQL query, building the operator tree in a Julia DSL and optimizing that, and then JITing the entire thing taking into account low level storage details and the particular sets of operators and joins (http://msr-waypoint.com/en-us/events/dcp2014/rompf.pdf). This is very exciting to see in another typed language!

Re: Julia: A fresh approach to numerical computing

#83

Post by canjobear » Sat, Nov 08, 2014, 5:51 PM UTC

andreasvc wrote: post #69

jghn wrote: post #33

Earlier quoted context omitted.

It's more natural to you (and to be fair, most programmers who have used OOP languages) purely because you're used to languages which work that way.

No, it is not some arbitrary choice, it confirms to the [second] most dominant word order in natural languages: subject-verb-object.

In fact, the most common word order in natural languages is subject-object-verb.

https://en.wikipedia.org/wiki/Subject%E2%80%93object%E2%80%9...

But SVO is a close second, and certainly more common than verb-subject-object (the equivalent of `function(arg1, arg2)`).

Re: Julia: A fresh approach to numerical computing

#84

Post by grayclhn » Sat, Nov 08, 2014, 5:58 PM UTC

one-more-minute wrote: post #79

grayclhn wrote: post #72

Earlier quoted context omitted.

I've seen julia described as "functional" a lot, but is that accurate? There are first-class functions for sure, but the "idiomatic julia" approach to a lot of problems is to allocate a large block of memory, pass around a reference to it and mutate it in place. i.e. all side effects. My terminology might be off, but that's not usually what I think of when I think of functional programming.

I think there's a distinction between idiomatic code and code written for performance. Performance-conscious code looks a lot like C in most languages, not just Julia. Julia just happens to have a lot of that kind of code because it makes it easy to write. But look at the high-level, user APIs and you tend to see the more functional side – `fft(x)`, `plot(y)` etc., all pure functions which return expressions. Mutatio…

"Idiomatic" might have been the wrong way for me to put it, but it seems like one of the biggest advantages and fundamental design decisions of Julia is that it makes numerical computing through side effects _very easy_. Most performance-conscious code doesn't just look like C in other languages, it is C! So I see your point, but I still wish there were a better way to convey exactly the mix of high and low level code that Julia's aiming for.

Re: Julia: A fresh approach to numerical computing

#85

Post by orbifold » Sat, Nov 08, 2014, 5:58 PM UTC

4ad wrote: post #19

termain wrote: post #17

Earlier quoted context omitted.

Typed Racket?

Never heard of it. Will check it out.

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).

Re: Julia: A fresh approach to numerical computing

#86

Post by carterschonwald » Sat, Nov 08, 2014, 6:01 PM UTC

wbhart wrote: post #54

From the article: " A pervasive idea that Julia wishes to shatter is that technical computing languages are “prototyping” languages and one must switch to C or Fortran for performance. The consequences to scientific computing have been more serious than many realize." I think this provides a very succinct summary of the Julia paradigm at a very high level.

I'm trying to push haskell for that too. But the more decent tools and choices, the better for everyone. :-)

Re: Julia: A fresh approach to numerical computing

#87

Post by tcbawo » Sat, Nov 08, 2014, 6:05 PM UTC

RivieraKid wrote: post #11

monochr wrote: post #4

What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn'…

One of the few things I don't like is that it lacks a bit for object-oriented programming. Specifically: - It doesn't use the object.method() syntax, which is often more natural and readable than method(object). - Support for interfaces but I'm not 100% sure about that.

It is interesting that in future versions of C++, object.method() is an active area of discussion: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n416...

Re: Julia: A fresh approach to numerical computing

#88

Post by canjobear » Sat, Nov 08, 2014, 6:07 PM UTC

one-more-minute wrote: post #79

grayclhn wrote: post #72

Earlier quoted context omitted.

I've seen julia described as "functional" a lot, but is that accurate? There are first-class functions for sure, but the "idiomatic julia" approach to a lot of problems is to allocate a large block of memory, pass around a reference to it and mutate it in place. i.e. all side effects. My terminology might be off, but that's not usually what I think of when I think of functional programming.

I think there's a distinction between idiomatic code and code written for performance. Performance-conscious code looks a lot like C in most languages, not just Julia. Julia just happens to have a lot of that kind of code because it makes it easy to write. But look at the high-level, user APIs and you tend to see the more functional side – `fft(x)`, `plot(y)` etc., all pure functions which return expressions. Mutatio…

I recently started a project in Julia and, excited by the prospect of a smart JIT compiler, wrote everything in a declarative function style with maps, reduces, and filters. The result was slower than than equivalent Python code. I swallowed my aesthetic sense and rewrote every function imperatively, with for loops updating some mutable array, and now it is quite fast. But I am no longer enjoying coding as much. I switched to Julia for speed, but that speed seems to come at the cost of having to write very imperative code.

In terms of day-to-day programming, I'm not sure what makes Julia a better functional language than Python or Ruby. From my limited experience, it isn't speed.

I understand that work is under way to speed up anonymous function calls and to improve type inference on arrays resulting from `map`, etc. Once that is done then I will consider Julia a nice functional language.

Re: Julia: A fresh approach to numerical computing

#89

Post by grayclhn » Sat, Nov 08, 2014, 6:08 PM UTC

jostmey wrote: post #78

dagw wrote: post #77

Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations…

I've observed a huge performance boost over python -- I wrote a simple artificial neural network trained using backpropagation in both languages and my Julia code ran orders of magnitude faster. Something is clearly screwed up with your implementation of Julia. There is no way octave should be running faster.

Octave occasionally runs faster than Julia for transliterated vectorized vector and matrix operations. Julia then runs much faster when those operations are devectorized or replaced with builtin functions. But that's a pretty common source of these issues (at least on the mailing list.)

Re: Julia: A fresh approach to numerical computing

#90

Post by infinite8s » Sat, Nov 08, 2014, 6:19 PM UTC

ViralBShah wrote: post #9

sgt101 wrote: post #7

Earlier quoted context omitted.

I would say Julia sucks for embedded programming :); building graphical clients - although not badly as there are various js libaries that it can chat to, games programming, it's not great at data base interaction although once you have the data in it it is fine (frames). The last point is a bit of a development area I would expect to see because Julia has a console and this means that interactive querying would be g…

There is work happening on the UI side in Julia. While we are some ways away from building graphical clients in Julia, we do have GTK bindings and such. For some interesting ideas borrowed from Elm, do see: https://github.com/shashi/Patchwork.jl

Is anyone working on direct Qt bindings (I don't consider using PyCall a viable option). Qt is a bit harder to wrap since it is C++, but it look like Lua has been able to auto generate bindings based on the Qt headers.