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

171–180 of 211 posts

Re: The Julia Programming Language

#171

Post by bandarman »

olaf wrote: post #124
bandarman wrote: post #100

Earlier quoted context omitted.

Thanks for your suggestion. I tried that, but it wasn't it. I'm still getting lots of build errors, culminating with this: Saving to: `lapack-3.4.0.tgz' 2012-02-19 01:03:26 (55.3 KB/s) - `lapack-3.4.0.tgz' saved [6127787/6127787] make[3]: gfortran: Command not found make[3]: * [lsame.o] Error 127 /bin/sh: ./testlsame: not found /bin/sh: ./testslamch: not found /bin/sh: ./testdlamch: not found /bin/sh: ./testsecond: n…

Is package gfortran installed?

@olaf: I was missing gfortran and libncurses5-dev. It's working now, sweet. :)

Re: The Julia Programming Language

#172

Post by ozataman »

pwang wrote: post #169
fijal wrote: post #166

Earlier quoted context omitted.

I guess I should clarify that - performance sucks. There are obviously various ways around it, but you just can't write a lot of performance critical python that way and I guess this is one of the reasons why julia exists in the first place.

But if you look at the actual cutting edge research work in the HPC and scientific space, they are working on languages that allow domain experts to express computation using higher level primitives, not on fancy compiler techniques to make general purpose imperative languages like C or Python "automagically" run faster on single cores. The general consensus, if you look at languages like Chapel and Fortress and X10,…

That sounds like programming in Haskell :-)

Re: The Julia Programming Language

#173

Post by Inufu »

vorg wrote: post #159
StefanKarpinski wrote: post #134

Earlier quoted context omitted.

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

Yeah, but those don't sit directly on your keyboard.

Re: The Julia Programming Language

#174

Post by Peaker »

StefanKarpinski wrote: post #140
Peaker wrote: post #128

Earlier quoted context omitted.

We shape our tools and then our tools shape us. Be careful when generalizing from your own personal preferences and cognitive biases to what is easier for humans in general.

Well, for what it's worth, I certainly also "grew up" with 0-based indexing (actually, literally grew up since I was a kid when I learned Pascal). I'm just saying that 1-based has really grown on me and that I find myself thinking about avoiding off-by-one errors far less often when using 1-based indexing. There are other times when I really wish I was using 0-based indexing. However, I find that that latter are more…

My experience is the exact opposite.

I find 1-based indexing to be weird/illogical and prone to off-by-1 errors.

Inclusive/exclusive ranges as in Python along with 0-based indexing means the likelihood of any off-by-1 is negligible...

Re: The Julia Programming Language

#175

Post by vorg »

Inufu wrote: post #173
vorg wrote: post #159

Earlier quoted context omitted.

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

Yeah, but those don't sit directly on your keyboard.

Neither do many foreign language tokens like 我是加拿大人 but that doesn't stop me typing them in quickly using the IME. Admittedly those brackets aren't in any IME I know, but maybe they should be.

Re: The Julia Programming Language

#176

Post by disgruntledphd2 »

EricBurnett wrote: post #15
disgruntledphd2 wrote: post #9

I'm a little worried about some of those benchmarks. They appear to have benchmarked R from a few years back against 2011 Matlab, for instance. In addition, they provide no code used for the benchmarks. That being said, this looks really interesting, and I'm gonna bookmark it for when I have time to examine it properly (after the damn phd is finally submitted).

They do link to the code: https://github.com/JuliaLang/julia/tree/master/test/perf . It doesn't look like a very reliable microbenchmark - run test x 5 times - but it should provide a useful starting point if you want to run your own.

Thanks guys, I'm not sure how I missed that. The benchmarks look interesting, but it is strange how old an R version they used. That being said, its a really interesting language, and I look forward to playing with it.

Re: The Julia Programming Language

#177

Post by wbhart »

ViralBShah wrote: post #88
wbhart wrote: post #33

Earlier quoted context omitted.

It would certainly be nice if there was an option to use 0 based indices in blocks of code. It's understandable in that they are pitching at the technical community, and many mathematical papers and books are written with 1 based indices. But I am a mathematician who prefers 0 based indices.

Actually, it is quite easy to implement 0 based indices or any other indexing scheme in julia, since all the array indexing code is implemented in julia itself. https://github.com/JuliaLang/julia/blob/master/j/array.j#L15... I personally would find multiple indexing schemes confusing both for usage as well as to develop and maintain. Given that 1 based indexing seems to be a popular choice among many similar language…

The problem with changing it in the library is that you'd also have to change it everywhere arrays are used in Julia itself.

The only way I could think to manage it would be a pragma which switches 0-based on for a given file. But this is doubtlessly not trivial.

Or there is the less elegant option of introducing a new operator for 0-based arrays. But this is liable to cause confusion I think.

Re: The Julia Programming Language

#178

Post by wbhart »

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

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.

Re: The Julia Programming Language

#179

Post by crntaylor »

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…

Matlab already allows you to omit the 'end' from function definitions, which many people find easier to read, and my experience seeing people transition from Matlab/Octave to Python+Numpy+Scipy is that people get on board with indentation-delimited blocks, because that's the way they write code anyway. But I agree - at the moment it's a pretty trivial thing. As a heavy user of Matlab, R and Py+N+S I'm looking forward to trying out Julia.
Post reply on HN