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

151–160 of 211 posts

Re: The Julia Programming Language

#151

Post by StefanKarpinski »

ViralBShah wrote: post #85
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'…

We used to use curl until recently so that it would build just fine on OS X. We changed it to wget, because it just seems so much easier to use than curl, and we had to do some nasty stuff at one point to download a few libraries that I couldn't figure out how to do with curl. BTW, do try out the mac binaries if the build is an issue. We are still trying to make it all build seamlessly!

For the record "ease of use" was not why we switched to wget — there was (for a while) a dependency that could only be downloaded using wget's recursive downloading. That's not the case anymore, however, so we should really switch back to curl.

Re: The Julia Programming Language

#154

Post by StefanKarpinski »

nnnnni wrote: post #32

Obligatory xkcd: http://xkcd.com/927/ It's about standards, but it still applies.

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 together in one environment. That's very much the same philosophy that NumPy and SciPy have, and indeed, it much the same goal. The biggest issue with NumPy, IMO, is that Python arrays aren't designed with linear algebra and interoperability with libraries like BLAS and LAPACK in mind. This leads to the somewhat maddening distinction between Python arrays and NumPy vectors and matrices — and lots of conversion back and forth between them.

Re: The Julia Programming Language

#155

Post by SomeCallMeTim »

blacksqr wrote: post #142

Pardon the possible naïveté, but I'm so old I remember Ada. Seems that language was designed to address a very similar problem space. What does Julia offer that Ada doesn't? Or perhaps: why is ada so deficient that spending 2+ years inventing a new language was a better proposition than taking the time to improve Ada?

While there's a resurgence of interest in ADA recently, the general sense is that it's WAY overdesigned and heavy.

I came across this bit of humor a while back that communicates the general feeling well:

http://bit.csc.lsu.edu/~gb/csc4101/Reading/gigo-1997-04.html

If the problem IS that it's huge and inelegant, then the solution isn't to try to improve it, but to start from a clean slate. Julia looks like a reasonable attempt.

Re: The Julia Programming Language

#156

Post by sitkack »

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…

While you are at it could you support alternate syntaxes for the same Expr ? Perhaps encoding the syntax version at the top of the file or setting the reader at the top of the file? For those porting matlab code over either provide a tool to translate the source or put the reader in matlab compatible mode.

Re: The Julia Programming Language

#157

Post by nnnnni »

StefanKarpinski wrote: post #154
nnnnni wrote: post #32

Obligatory xkcd: http://xkcd.com/927/ It's about standards, but it still applies.

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.

Re: The Julia Programming Language

#158

Post by wbhart »

StefanKarpinski wrote: post #137
wbhart wrote: post #123

Earlier quoted context omitted.

Unfortunately the performance would be poor. This is not a reflection on Julia. Even compiled C is between 4 and 12 times slower than assembly for some bignum operations. Also, LLVM handles carries and certain loop optimisations poorly, so even using LLVM bytecode you can't do much better than compiled C. It would be a massive project to improve this in LLVM (I thought about giving it a go sone time ago but decided i…

That makes a whole lot of sense. For myself, I wouldn't even attempt this because it's so much harder and more time-consuming to try to reimplement something like bignums efficiently than it is to just use a stable, mature and fast external library like GMP or CLN — or something like your project if BSD/MIT licensing is a must.

It's been done. I think it was Gambit Scheme that had its own bignum library. And for a while, very large integer arithmetic was reportedly faster than GMP, which if you know anything about GMP is quite an achievement. However, the GMP guys subsequently fixed this problem.

Re: The Julia Programming Language

#159

Post by vorg »

StefanKarpinski wrote: post #134
warmfuzzykitten wrote: post #102

Earlier quoted context omitted.

Seems like an easy fix.

Using curly braces for blocking is a non-starter because they're used for a lot of other things, and honestly, bracket pairs like (), [], {} are way too precious, imo, to squander on something like blocks. Parens () are exclusively for function application; square brackets [] are exclusively for indexing operations; curly braces {} are for type parameterization. The other option that C++ popularized the use of is — b…

> bracket pairs like (), [], {} are way too precious, imo, to squander on something like blocks

I disagree. Besides (), [], {}, and , there's plenty of other paired punctuation available in Unicode, such as...

⦃⦄⦅⦆⦇⦈⦉⦊⦋⦌⦍⦎⦏⦐⦑⦒⦓⦔⦖⦕⦗⦘⧘⧙⧚⧛⧼⧽〈〉《》「」『』【】〔〕〖〗〘〙〚〛❨❩❪❫❬❭❮❯❰❱❲❳❴❵⟦⟧⟨⟩⟪⟫

Re: The Julia Programming Language

#160

Post by mietek »

dkarl wrote: post #105
muuh-gnu wrote: post #75

Earlier quoted context omitted.

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

Whitespace-based layout works quite well in Haskell: http://www.haskell.org/onlinereport/lexemes.html#lexemes-lay...
Post reply on HN