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

181–190 of 211 posts

Re: The Julia Programming Language

#181

Post by JulianMorrison »

StefanKarpinski wrote: post #119
dkarl wrote: post #112

Earlier quoted context omitted.

in any language where objects are boxed, it becomes very tricky. We're working on it, however Naive question (and I'll hold my tongue on my naive guesses): I understand why it is necessary to box user-defined types on the JVM, but why build this restriction into a new language that doesn't run on a restricted platform? Especially when performance and C interop are high priorities? Or perhaps I misunderstood, and your…

Boxed values are pretty much necessary for dynamic languages — that's where the information about what kind of value something is gets stored. It is a pain for this kind of thing, however. In a fully statically compiled language like C, however, you can eliminate the need for a box entirely. If you want dynamic typing, that's the price we've gotta pay.

Take a look at how Go handles interface types, because that is basically dynamic typing, and Go can allocate data as unboxed values.

Re: The Julia Programming Language

#182

Post by [deleted] »

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…

[deleted]

Re: The Julia Programming Language

#183

Post by gtani »

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…

It's worth looking at the PPL project

http://ppl.stanford.edu/main/publications.html

example, this scala DSL:

http://liszt.stanford.edu/liszt_sc2011.pdf

Re: The Julia Programming Language

#185

Post by acqq »

StefanKarpinski wrote: post #118
pron wrote: post #95

Earlier quoted context omitted.

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

No, currently it's an inline array of immutable 128-bit numeric values and we use bit-twiddling to pull the real and imaginary parts out. However, that's a temporary hack. (It's also why the mandel benchmark is relatively slow — all the bit-twiddling is not very efficient.) The longer-term approach is still up in the air and that's what I was talking about above. My favorite approach at this point is to allow fields…

Can you please explain or give a link what the problem really is (that is, why do you have "bit twiddling" at all) and how you imagine that const arrays of complex can be write once and still efficient?

What's the problem to have arrays of doubles and complexes as "basic" types even in the dynamic language? I believe this could give you a C footprint and C performance with array operations?

Re: The Julia Programming Language

#186

Post by StefanKarpinski »

pron wrote: post #122
StefanKarpinski wrote: post #119

Earlier quoted context omitted.

Boxed values are pretty much necessary for dynamic languages — that's where the information about what kind of value something is gets stored. It is a pain for this kind of thing, however. In a fully statically compiled language like C, however, you can eliminate the need for a box entirely. If you want dynamic typing, that's the price we've gotta pay.

Not necessarily. You just store a pointer to the type info inline with the data (like C++'s vtables). You can have unboxed "value-types" (const structs, essentially) in dynamic languages. In fact, you could even differentiate between a "boxed" ref type and a value type at runtime, because refs don't need all 64 bits of the pointer. So a ref is a 64 bit pointer with the first bit set to, say, 0, and a value (struct) t…

Ok, having read this comment again, here's a more measured response. You're assuming in this comment the value-type vs. object-type dichotomy that's used in, e.g., C#. That's one way to go, but I'm not sold that it's the best way. Deciding whether you want something to be storable inline in arrays or not when you define a type is kind of a strange thing. Maybe sometimes you do and sometimes you don't. So the bigger question is really if that's the best way to go about the matter.

It seems that in dynamically typed languages, you either need to have two kinds of objects (value types vs. object types), or two kinds of storage slots (e.g. arrays that hold values inline vs. arrays that hold references to heap-allocated values). The boxing aspect is really only part of that since you can't get the shared-reference behavior unless the storage is heap-allocated, regardless of whether there's a box header or not.

So yeah, it's a complicated issue.

Re: The Julia Programming Language

#187

Post by samth »

vorg wrote: post #162
StefanKarpinski wrote: post #147

Earlier quoted context omitted.

That is very true — and it's precisely why we have considered making macros callable with function syntax. But I feel like having something that looks like a function and is actually a macro is a bit of a dangerous lie, no matter how handy it sometimes is. One of our design goals is not to be too tricky — if something looks like a function call, it should be a function call. The @foo syntax for macro calls means that…

If macros are marked as different to functions at the callsite, then do they need to be marked different at the definition site? Most functions return a non-Expr value, but could return a Expr if the program's job is manipulating them. Most macros return a Expr, but could return a literal for insertion into the code. So I'm wondering does a programming language which marks macro expansions different to function calls…

Template Haskell, which uses an explicit mark at macro calls (a $), doesn't require marking macro definitions explicitly, so it can certainly be done.

Re: The Julia Programming Language

#188

Post by ViralBShah »

nnnnni wrote: post #157
StefanKarpinski wrote: post #154

Earlier quoted context omitted.

I realize this is just a comic, but it's one of the reasons that we try to be as compatible with C and Fortran libraries as possible — that's where the vast bulk of high-quality scientific computing work has been done, and we want to be as compatible with it as possible. The goal here is not to duplicate all the work that's already been done, but to allow existing high-quality libraries to be smoothly and easily used…

I also posted that comment without reading the article -- that was just my first response to "yet another programming language". I'm sure that it's filling a real need. I just wish that groups could cooperate to make a handful of languages/libraries better rather than having 100 competing ones.

Actually, there is much more co-operation than is visible. Almost all the groups share the same libraries, same bugfixes, same patches, etc., which typically will account for much of the user experience.

The different language approaches will typically compete on things like syntax, speed, etc., and this leads to innovation and cross-pollination of ideas. I personally prefer to have some choice, and use a number of languages for scientific computing myself - but I guess too much choice makes things confusing for the newcomer.

Re: The Julia Programming Language

#189

Post by wbhart »

wbhart wrote: post #178
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…

Is the documentation still accurate on that there is no way to pass structs from Julia to C? One other slight difficulty seems to be the lack of finilisers, e.g. to clean up a GMP bignum when there are no remaining references to it.

Ah, there are finalisers. The function finalizer lets you define a function to be called when there are no more references to an object. I guess maybe the idea is to use this from within the constructor.

Re: The Julia Programming Language

#190

Post by ViralBShah »

warmfuzzykitten wrote: post #99

When you try to install julia on MacOS X 10.7.3, you may see the make fail because wget is not installed. Easy to fix with: brew install wget [Edit] git page says gfortran (and wget) are downloaded and compiled, but if they're not already installed make fails. So... brew install gfortran The need to do this separately may have to do with licensing? [Edit] And if you're not root, install to /usr/share/julia will fail.…

Someone just submitted a patch that uses curl on OS X. Also, no need for root, because julia will run out of the directory it is built in. Hopefully, someone who knows more about mac packaging will build a drag-and-drop installer.
Post reply on HN