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

The Julia Programming Language

julialang.org

Post reply on HN
Print view View original

101–110 of 211 posts

Re: The Julia Programming Language

#101

Post by dkarl »

gtani wrote: post #68
pron wrote: post #48

Earlier quoted context omitted.

I've been waiting for Fortress for a LONG time, but either progress has been real slow or the Fortress team has trouble communicating their progress to the community. Probably both. From a quick look I can tell that while Fortress is more similar to Scala, with classes, mixins and static typing, Julia is closer to Clojure, with no encapsulation, dynamic typing, homoiconicity, and separation of behavior (methods) from…

I think i've been waiting for Chapel more than X10 or Fortress, but scala and clojure are assuming the mantles as general purpose languages. http://bartoszmilewski.wordpress.com/2011/11/07/supercomputi... http://lambda-the-ultimate.org/node/4405

Languages built on the JVM have to deal with boxing and unboxing. Scala still doesn't have efficient arrays of unboxed values. Progress here: http://docs.scala-lang.org/sips/pending/value-classes.html

After that proposal is implemented (perhaps in version 3 of Scala, almost ten years after its first release, though granted it wasn't their top priority) they'll still have to write at least a little bit of boilerplate for each type they want to store in unboxed arrays, and they'll be limited to types that can be stored as Java primitive types under the covers. That seems like a pretty nasty limitation for a general-purpose scientific computing language, not only because it decreases native performance but because it makes C interop much more difficult.

For a general-purpose scientific language, I think it is imperative to adopt the principle that any user-designed type should be able to achieve the same power, performance, and elegance as if it were a built-in type. To the best of my knowledge, that rules out JVM languages.

(Scala was never meant to be a "JVM language," but in terms of its strengths, its weaknesses, its user base, and its future, it is very much a JVM language, and the obstacles to implementing efficient user-defined types is one of the trade-offs they accepted when they went with the JVM.)

Re: The Julia Programming Language

#102

Post by warmfuzzykitten »

muuh-gnu wrote: post #75
StefanKarpinski wrote: post #67

Earlier quoted context omitted.

Yeah, we've been waiting for a while for Fortress too. It seems like a lot of time and effort has gone into a WYSIWYG IDE and not as much into the actual language implementation :-( Chapel has made a lot of progress in the past 2.5 years (while we've been working on Julia) and is certainly a contender. Julia certainly aims to be more dynamic like Clojure, but specially designed to be good for numerical and technical…

> he begin/end is due to Matlab Octave has solved this by allowing both matlab-style "end", as well as block-specific endings, like "endif", "endfunction", "endfor", etc. Having several end end end endings without any hint of what they are closing is one of the ugliest parts of matlab. Even though you are reimplementing this for compatibility reasons, it is rather sad that you chose to make this the default behaviour…

Seems like an easy fix.

Re: The Julia Programming Language

#103

Post by mjw »

fijal wrote: post #39
mjw wrote: post #26

I wonder what they think about or have learned from http://en.wikipedia.org/wiki/Fortress_(programming_language) , another recent-ish attempt to deliver a modern and powerful scientific programming language. Personally I'm a little wary of being ghettoised into something overly domain-specific for scientific/numerical computing. Really good interop may mitigate that -- something which can navigate the unholy mix of C…

Python+numpy+scipy does work only if you actually don't write much python or at least not run much python. Otherwise it sucks

OK, perhaps I should have qualified that. It's a good 90% solution for a lot of use cases, although obviously more useful for implementing algorithms in terms of numerical building blocks, than ultra-performance-critical code where you want to write a lot of your own tight inner loops. Is that what you meant?

The parallelisation story isn't great at the moment either, although seems like it has the potential to improve. Still 'sucks' is pretty harsh. For me, looking at how far it's come since I first played with it, I'm impressed. For machine learning, the majority of the building blocks one needs are there, and you get to sit back and put them together using a nice, clean, widely-adopted general purpose programming language. And unlike MATLAB still maintain a decent amount of control over things like memory usage and which BLAS routines it's calling.

Adding bindings for new libraries is more of a pain than it should be though on the occasions where you do really need some fortran or C++ library that doesn't have bindings yet. A language which bridges the gap between high and low levels (not C++!) and has great interop would be very interesting. I guess I'm just hopeful that this kind of thing can be achieved in a general-purpose language (new or existing) which like Python is adopted across the wider software engineering community. Perhaps that's my unreasonable demand to add to their list :)

Re: The Julia Programming Language

#104

Post by warmfuzzykitten »

wbhart wrote: post #87
StefanKarpinski wrote: post #74

Earlier quoted context omitted.

At first we were going to use 0-based indexing, but it made porting any Matlab code over very hard, which defeats a large part of the purpose of having Matlab-like syntax in the first place — to leverage the large amount of Matlab code and expertise that exists out there. However, as I've used it more and more, 1-based indexing has really grown on me. I feel like I make far fewer off-by-one errors and actually hardly…

Many divide-and-conquer algorithms seem to be easier to express with 0 based indexing, whereas quite a few array operations seem to be better with 1 based indexing. I can certainly understand and appreciate the different points of view, I just personally always think about algorithms with 0-based arrays.

As does anyone trained in the C tradition, but it's annoying, too, to have to translate 1-based math formulas to the C convention. Having recently used Octave for the Stanford online ML class after a couple decades of C, C++ and Java, I doubt programmers will have trouble with the mental transition.

Re: The Julia Programming Language

#105

Post by dkarl »

muuh-gnu wrote: post #75
StefanKarpinski wrote: post #67

Earlier quoted context omitted.

Yeah, we've been waiting for a while for Fortress too. It seems like a lot of time and effort has gone into a WYSIWYG IDE and not as much into the actual language implementation :-( Chapel has made a lot of progress in the past 2.5 years (while we've been working on Julia) and is certainly a contender. Julia certainly aims to be more dynamic like Clojure, but specially designed to be good for numerical and technical…

> he begin/end is due to Matlab Octave has solved this by allowing both matlab-style "end", as well as block-specific endings, like "endif", "endfunction", "endfor", etc. Having several end end end endings without any hint of what they are closing is one of the ugliest parts of matlab. Even though you are reimplementing this for compatibility reasons, it is rather sad that you chose to make this the default behaviour…

I agree. If all they say is "end end end" you might as well use braces. I'm depressed to hear that Matlab is an inspiration to the language design at all; the Matlab language is by far the worst aspect of Matlab, and it has nothing to recommend it. Think of the damage that Sun did to Java to make it look familiar to C programmers; no need to repeat that mistake (though if you're cynical, you might think it was the smartest thing they ever did.)

Braces would be better than ending keywords, in my opinion, but I'm disappointed not to see whitespace-defined blocks of a la Python. Perhaps that doesn't work in a statically-typed, type-inferred language, but if it does, I think it would be much better. Scientists have no problem with it (certainly less of a problem than programmers do) and Python is pretty well accepted in the scientific computing community.

Re: The Julia Programming Language

#106

Post by marshray »

cheald wrote: post #54
wbhart wrote: post #28

Much praise!! These guys have incredibly good taste. Almost every single thing I can think of that I want in a programming language, they have it. All in the one language! The fact that it has parametric types, parametric polymorphism, macros, performance almost as good as C, good C/Fortran interop, 64 bit integers and an interactive REPL all in the one language just blows my mind. I wasn't able to tell if it is poss…

When reading through the manual, I was struck at how similar the language seems to be to Lua, at least superficially. Lua also has 1-based arrays. Heh.

I noticed that too.

The language syntax seemed uninteresting, which is not really a bad thing but what's the case for the need for a whole 'nother language in that category?

Re: The Julia Programming Language

#107

Post by pron »

dkarl wrote: post #101
gtani wrote: post #68

Earlier quoted context omitted.

I think i've been waiting for Chapel more than X10 or Fortress, but scala and clojure are assuming the mantles as general purpose languages. http://bartoszmilewski.wordpress.com/2011/11/07/supercomputi... http://lambda-the-ultimate.org/node/4405

Languages built on the JVM have to deal with boxing and unboxing. Scala still doesn't have efficient arrays of unboxed values. Progress here: http://docs.scala-lang.org/sips/pending/value-classes.html After that proposal is implemented (perhaps in version 3 of Scala, almost ten years after its first release, though granted it wasn't their top priority) they'll still have to write at least a little bit of boilerplate…

I agree, and I think Julia's designers have chosen correctly not to use the JVM (although, in the comments below you'll find that Julia uses boxed types for "structs" as well, though it would be far easier to build true array-embeddable complex types on LLVM than on the JVM). However, value types for the JVM are a work in progress (as well as tail-calls), and I think they might have already been implemented in the DaVinchi project (future JVM improvements), and so will find their way to the JVM in due time (see https://blogs.oracle.com/jrose/entry/tuples_in_the_vm). Until then, scientific computing languages will most likely choose a different platform.

Re: The Julia Programming Language

#108

Post by jfager »

mjcohenw wrote: post #80

I am currently building it - OS X Lion. First, I had to install wget:) Then, I got a certificate error on the https, so I pasted the command into Firefox and got the tarball. After copying it to the julia dir, I edited the tar command and ran it. Finally, doing make right now. Here is the certificate error: Connecting to github.com (github.com)|207.97.227.239|:443... connected. ERROR: The certificate of `github.com'…

For anyone else who hits this, this should get you going:

http://loopkid.net/articles/2011/09/20/ssl-certificate-error...

Basically, you need to get the right certs and then tell wget to use them.

Re: The Julia Programming Language

#109

Post by sparsevector »

pron wrote: post #95
StefanKarpinski wrote: post #71

Earlier quoted context omitted.

I huge part of the goal here is to reduce the need for the "unholy mix of C, C++, fortran, matlab, octave, R and python routines" in both academic research work and machine learning / data science code in industrial settings. The whole project kicked off with me ranting about how I was sick of cobbling things together in six or seven different languages. So interop is a very, very high priority. We have pretty good C…

> Another major interop issue is support for arrays of inline structs Oh, so arrays of complex numbers are implemented as arrays of pointers to objects? That would give really bad CPU cache performance.

It sounds like he's saying it's hard for Julia to interop with languages that don't support arrays of inline structs (e.g. Java). I could be misreading it though.
Post reply on HN