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

71–80 of 211 posts

Re: The Julia Programming Language

#71

Post by StefanKarpinski »

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…

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 ABI interop now. You can just call a C function like this:

  ccall(:getpid, Uint32, ())
and it works. It works in the repl too and you can dynamically load new libraries in the repl. See this manual page for more details: http://julialang.org/manual/calling-c-and-fortran-code/.

We still want better C/C++ interop though. I've already looked into using libclang so that if you have the headers you don't even have to declare what the interface to a function is. That was very preliminary work, but I got some stuff working. Making Julia versions of C struct types transparently would be another goal here.

Another major interop issue is support for arrays of inline structs (as compared to arrays pointers to heap-allocated structs). C can of course do this, but in any language where objects are boxed, it becomes very tricky. We're working on it, however, anyone who wants to discuss, hop on julia-dev@googlegroups.com :-)

Re: The Julia Programming Language

#73

Post by StefanKarpinski »

tomp wrote: post #59
samth wrote: post #25

Earlier quoted context omitted.

It's great the metaprogramming support seems to be a requirement for new languages these days. Unfortunately, this one combines the inconvenience of Template Haskell (explicit invocation of macros with @) and the bugs of Common Lisp (the section on hygiene says, basically, "we have gensym"). Fortunately, the language is young, and I hope they can improve this story.

What else would you suggest? I find that the @ syntax is amazing, since the reader (programmer) knows exactly which form is a macro (and can look it up), as opposed to introducing arbitrary, often very confusing syntax.

Thanks. We've considered doing other things — like function call syntax for macros (which is essentially what Lisp/Scheme have), but decided against it. It just causes confusion. Can you pass a macro around like you can a function? Can functions shadow macros and vice versa? What happens if a macro introduces a local variable that shadows the macro itself? Basically it comes down to fact that macros are syntactic and as such behave very differently from functions, which are not syntactic. With the @ syntax, there's no confusion.

Re: The Julia Programming Language

#74

Post by StefanKarpinski »

ludwigvan wrote: post #56
maximilian wrote: post #44

Earlier quoted context omitted.

Fortran is 1-index as well. I think MATLAB gets its notational style from Fortran.

Actually, broadly speaking, I think math (think summation etc.) in general is usually 1-index based while programming is 0-index (due to memory locations so that the array index also points to the first element?). Also see Dijkstra's take on the matter: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF for

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 ever have to think about them. This has led me to conclude that 1-based indexing is probably easier for humans while 0-based indexing is clearly easier for computers.

Re: The Julia Programming Language

#75

Post by muuh-gnu »

StefanKarpinski wrote: post #67
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…

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 for Julia.

Re: The Julia Programming Language

#76

Post by StefanKarpinski »

kghose wrote: post #45

So, the usual caveats about writing code to match the languages strengths apply here. For example the fib function plays to a python weakness - function overhead. Rewriting the code to be a simple loop removes the inefficiency: import time def fib(n): if n

That's quite true, but this micro-benchmark wasn't chosen to make Python look bad — it was chosen to test how good each language was at function calls. So using a loop defeats the point of the benchmark. Using double recursion to compute Fibonacci numbers is also stupid and could obviously be avoided in all languages.

The story the micro-benchmark tells is that Julia's pretty good at function calls, but JavaScript is even better (and, of course, C/C++ is the gold standard). In general the V8 engine is really amazing. We had the advantage of being able to design the language to make the execution fast (with the constraints of all that we wanted to be able to do with it), but V8 makes a language that was in no way designed for performance and makes it blazingly fast.

After I wrote the benchmark code for JavaScript and saw just how fast it was I had a moment of "should we be doing scientific computing in JavaScript?" Now wouldn't that be nuts?

Re: The Julia Programming Language

#78

Post by StefanKarpinski »

andrewcooke wrote: post #30

this is surprisingly complete for a relatively new(?) project. one notable restriction is that inheritance is only for interface, not implementation. also, can anyone find a sequence abstraction (like lists)? arrays seem to be fixed size and i don't see anything else apart from coroutines. am i missing something?! [perhaps not, if it's intended for numerical work. on reflection i am moving more and more towards gener…

pron is right: you can inherit behavior from abstract types and abstract types, unlike interfaces, can have code written to them. (In single-dispatch OO languages, you are in the strange situation that you can write code to interfaces if they are arguments but not if they are the receiver of a method; thus, you're in a situation where you can either dispatch on an interface or you can write code for it, but never both at the same time.)

Arrays are not fixed size: there are push, pop, shift and unshift operations on them just like Perl, Ruby, etc. This uses the usual allocation-doubling approach so that the entire array doesn't need to be copied every time, but it's still usually much better to pre-allocate the correct size. Of course for small arrays that are typical in Perl, Ruby, etc., it hardly matters. If you're building an vector of 1 billion floats, however, you don't want to grow it incrementally.

The sequence/iterable abstraction is duck-typed: an object has to implement methods for three generic functions:

  i = start(x)
  done(x,i)
  next(x,i)
The state i can be anything.

Lack of implementation inheritance is one of those things that intro to OO books make a big deal of, but when you don't have it, you don't miss it at all — or at least I don't. I've never found tacking a few fields onto the end of an object to be very useful. I don't want to inherit memory layout — I want to inherit behavior. Julia's type system lets you write behavior to abstract types and inherit that for various potentially completely different underlying implementations.

Re: The Julia Programming Language

#80

Post by mjcohenw »

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' is not trusted. ERROR: The certificate of `github.com' hasn't got a known issuer.

Post reply on HN