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

Re: Julia: A fresh approach to numerical computing

#21

Post by runarberg » Sat, Nov 08, 2014, 1:03 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.

When you think in types rather then objects it makes more sense. Or at least I think `+(u, v)` or `u + v`, is more natural then `u.plus(v)` or `u.+(v)`

I the former case u and v are of numeric types that fulfil some numeric properties, so no interfaces are necessary, they are implied.

Re: Julia: A fresh approach to numerical computing

#22

Post by RivieraKid » Sat, Nov 08, 2014, 1:03 PM UTC

one-more-minute wrote: post #15

RivieraKid wrote: post #11

Earlier quoted context omitted.

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.

Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.

I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.

Re: Julia: A fresh approach to numerical computing

#23

Post by qooleot » Sat, Nov 08, 2014, 1:05 PM UTC

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'…

Julia's http library, and furthermore the extensive communities around tech stacks like node.js and ruby. Although Julia is focused on mathematical problems, its still often important to pull data from resources on the net (google weather just as a trivial example). Or outputting results to a website to share results dynamically. This is one area where Python shines - being both a strong web framework (Flask and Django)as well as with scipy and pandas library for computation.

As a bootstrap to letting us do things like stream audio from the Web Audio API, and use Julia inside of an existing web app was to build a Node.js and Julia bridge:

https://github.com/waTeim/node-julia

It worked out very conveniently that Node.js through node-gyp can use C libraries, and Julia can run inside a C context.

I think the strongest use cases are node streams, and also online-learning models such as a recommender system. I.e. pass to Julia what the user has been interested in, and simply get back a few suggested items of high correlation.

Re: Julia: A fresh approach to numerical computing

#24

Post by RivieraKid » Sat, Nov 08, 2014, 1:05 PM UTC

termain wrote: post #18

RivieraKid wrote: post #11

Earlier quoted context omitted.

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.

Object.method() doesn't really make sense due to multiple dispatch, I think.

Why? It can be just a syntactic sugar for method(object).

Re: Julia: A fresh approach to numerical computing

#25

Post by edelman » Sat, Nov 08, 2014, 1:10 PM UTC

Yes, this paper, as the title suggests, was written perhaps for the community as a whole, but perhaps in particular for the numerical computing community. Most especially, there are many ideas in this paper that are entirely unfamiliar to that community, and this paper hopes to change that. Hope you enjoy the reading. (We probably will make some updates. The spelling fix of the title was already processed yesterday and will appear tomorrow or Monday.)

Re: Julia: A fresh approach to numerical computing

#26

Post by one-more-minute » Sat, Nov 08, 2014, 1:12 PM UTC

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 crazy code specialisation, including on e.g. matrix dimensions or generating appropriate FFI calls based on arbitrary input types. It has zero overhead and you can use it just like a regular function.

Very cool, and I think people will do really interesting things with this (especially after mixing them with macros).

Re: Julia: A fresh approach to numerical computing

#27

Post by jghn » Sat, Nov 08, 2014, 1:14 PM UTC

thebelal wrote: post #16

amelius wrote: post #8

Earlier quoted context omitted.

What I'd like to know when learning a new language is: why can't this be done in an existing language? Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.

R (1976)[1] and Matlab (1984)[2] both predate Python (1991)[3], so I guess the answer is because the 'existing' language didn't exist. As far as Julia goes it aims to bring strong typing and very fast native performance for numerical operations. Neither of which R, Matlab, or Python provide. Seems perfectly reasonable to me. [1]: http://en.m.wikipedia.org/wiki/S_(programming_language) [2]: http://en.m.wikipedia.org/w…

Uhh, R is not from 1976, S is - as you note from your footnotes.

There's a direct and strong lineage, but they're not the same.

As someone who remembers when version 1.0 of R was released, I can say pretty confidently that it was well after 1976 :)

Re: Julia: A fresh approach to numerical computing

#28

Post by jghn » Sat, Nov 08, 2014, 1:16 PM UTC

RivieraKid wrote: post #22

one-more-minute wrote: post #15

Earlier quoted context omitted.

Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.

I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.

When you say "OOP approach", I'm reading "OOP in the style of the C++/Java/C#/etc branch of the OOP family tree".

Not all OOP languages look remotely like what you're describing.

Re: Julia: A fresh approach to numerical computing

#29

Post by RivieraKid » Sat, Nov 08, 2014, 1:17 PM UTC

runarberg wrote: post #21

RivieraKid wrote: post #11

Earlier quoted context omitted.

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.

When you think in types rather then objects it makes more sense. Or at least I think `+(u, v)` or `u + v`, is more natural then `u.plus(v)` or `u.+(v)` I the former case u and v are of numeric types that fulfil some numeric properties, so no interfaces are necessary, they are implied.

> Or at least I think `+(u, v)` or `u + v`, is more natural then `u.plus(v)` or `u.+(v)`

I definitely agree with that, I said that object.method() style is often more natural. Typically when you have an object with some internal state and you want to send a message to it that will change its state. For example: threadPool.run(command) feels more natural than run(thread_pool, command).

Re: Julia: A fresh approach to numerical computing

#30

Post by one-more-minute » Sat, Nov 08, 2014, 1:19 PM UTC

RivieraKid wrote: post #22

one-more-minute wrote: post #15

Earlier quoted context omitted.

Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.

I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.

Believe it or not it's actually perfectly feasible to implement first-class objects and inheritance on top of Julia. You can even integrate it with multiple dispatch (via some metaprogramming and manipulation of the type system) and get object~method(x,y) syntax.

I didn't want it enough to flesh out the prototype (and would argue that Julia's native approach is better anyway) but it's inevitable that someone will do this eventually.