Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia: A fresh approach to numerical computing

arxiv.org

Post reply on HN
Print view View original

31–40 of 146 posts

Re: Julia: A fresh approach to numerical computing

#31

Post by desdiv »

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.

If a language makes the dot and the method invocation brackets optional, then `u + v` and `u.+(v)` would be semantically identical. The former would just syntax sugar for the latter.

Re: Julia: A fresh approach to numerical computing

#33

Post by jghn »

RivieraKid wrote: post #29
runarberg wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Julia: A fresh approach to numerical computing

#35

Post by RivieraKid »

jghn wrote: post #28
RivieraKid wrote: post #22

Earlier quoted context omitted.

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.

> I'm reading "OOP in the style of the C++/Java/C#/etc branch of the OOP family tree".

You read mostly right. But the OOP language I like the most is Ceylon (it also has a first-class support for the functional paradigm).

Re: Julia: A fresh approach to numerical computing

#36

Post by jghn »

RivieraKid wrote: post #35
jghn wrote: post #28

Earlier quoted context omitted.

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.

> I'm reading "OOP in the style of the C++/Java/C#/etc branch of the OOP family tree". You read mostly right. But the OOP language I like the most is Ceylon (it also has a first-class support for the functional paradigm).

In particular I'm thinking of things like Dylan or CLOS. When people from the more typical OOP backgrounds see stuff like that often their heads explode.

I recently got into an argument with some coworkers over type classes. My argument was that it all made sense when viewed from the Dylan/CLOS/S4/etc lens, and that this was very much OOP, just not what they were used to. Many of them weren't buying what I was selling, but IMO they were using too strict a definition of OOP.

Re: Julia: A fresh approach to numerical computing

#37

Post by Immortalin »

4ad wrote: post #14
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.

Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions. Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this. Now, is there any other language with Lisp-like macros and static typing?

Typed clojure

Re: Julia: A fresh approach to numerical computing

#38

Post by jules »

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.

Julia supports multiple dispatch OO, which is more powerful than what you get from traditional OO languages. Or do you purely mean the x.foo(y) syntax rather than foo(x,y)?

Re: Julia: A fresh approach to numerical computing

#39

Post by RivieraKid »

jghn wrote: post #33
RivieraKid wrote: post #29

Earlier quoted context omitted.

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

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.

> purely because you're used to languages which work that way.

You don't know that. I think that for people new to programming both styles can be natural, depending on the specific situation.

Re: Julia: A fresh approach to numerical computing

#40

Post by fdej »

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 non-incremental stop-the-world garbage collector is quite bad.

I ran into problems with this when trying to implement an algorithm that creates and destroys lots of temporary objects, where each object is a wrapped C struct that can point to a large amount of extra memory (the algorithm in question is doing polynomial division, where each coefficient is a polynomial represented by a C object).

The Julia version of this program runs unexpectedly slowly and uses gigabytes of memory, even though a few megabytes should be enough. The same code runs much faster if you do it in C and free every temporary object when it's no longer used, or even you do it with a Python C extension. Since Python uses reference counting, the objects get freed as soon as they fall out of scope.

But Julia allocates thousands of objects at a time before running the GC. Inserting manual GC calls is even worse -- the memory usage drops, but the program slows down by an order of magnitude (every GC takes a long time, even if you've just allocated a couple of objects since the last time).

Part of the problem is that the C code in question uses an object pool to speed up frequent allocations and deallocations. But even if you disable the pool, Julia performs worse than you would hope. A good generational/incremental GC would solve the problem.

Post reply on HN