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

Static, Ahead of Time Compiled Julia

juliacomputing.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Static, Ahead of Time Compiled Julia

#81

Post by vanderZwan »

jedharris wrote: post #72
openasocket wrote: post #57

Earlier quoted context omitted.

I disagree: strong and weak typing are fairly well defined terms. I'm going off the definition given in "Programming Language Pragmatics," which states "a language is strongly typed if it never allows an operation to be applied to an object that does not support it; a language is said to be statically typed if it enforces strong typing at compile time."

Even if you are correct that they are well defined, by that definition Lisp, Ruby, Python, JavaScript and Julia are strongly typed. C, Forth and assembly language are not. So the distinction isn't useful in this discussion.

Well, Forth is considered untyped, which I think is apt: it's basically bytes on a stack passed between words, with semantic meaning completely in the programmer's head and hopefully well-documented.

With that in mind, shouldn't we expect it to be a good base case for describing the "weakest typed" language?

Re: Static, Ahead of Time Compiled Julia

#82

Post by lmm »

acidflask wrote: post #56
lmm wrote: post #45

Earlier quoted context omitted.

> I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box. Did you look at MLlib and/or just using Breeze directly? There's a bit of awkwardness in the initial set up of the cluster (mainly just having LAPACK installed on all nodes, see https://spark.apache.org/docs/1.1.0/mllib-guide.htm…

Most people don't need more than a handful of linear algebra operations (or think they don't), so Breeze and most wrappers of LAPACK or similar libraries don't implement or wrap them. But most people who work seriously on numerical routines will quickly run into performance problems if all they do is call LAPACK routines for general matrices instead of taking advantage of matrix structure. I have yet to come across a…

Something like the Scala type system seems like the best way to keep track of that kind of structure information and make use of it (perhaps even transparently). I can easily believe the current wrappers aren't there yet though. (Afraid I switched jobs six months ago and haven't been using Breeze or Spark since, so I can't justify working on it myself at the moment)

Re: Static, Ahead of Time Compiled Julia

#83

Post by vanderZwan »

StefanKarpinski wrote: post #74
nickpsecurity wrote: post #70

Earlier quoted context omitted.

Luu's claims made me hold off on pushing people to contribute to Julia as I waited for corroboration (or refutation) of them. I appreciate you linking to that very fair post that replies to it. The contrast between how the two of your present your claims adds credibility to yours. I also got a great laugh out of part about one guy that barely speaks English using the project as a personal Stackoverflow. A problem I'd…

The parser and some lowering passes are still written in femtolisp. There has been some discussion of switching to the native JuliaParser package [1]. However, JuliaParser doesn't implement the fairly tricky lowering passes that the femtolisp parser does. I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the pars…

> I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the parsing and lowering will be converted to C instead.

But isn't Julia supposed to be fast? ;)

Re: Static, Ahead of Time Compiled Julia

#84

Post by conjectures »

lmm wrote: post #45
conjectures wrote: post #42

Earlier quoted context omitted.

It's an MCMC algorithm for a fancy kind of matrix factorisation. I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box. Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?

> I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box. Did you look at MLlib and/or just using Breeze directly? There's a bit of awkwardness in the initial set up of the cluster (mainly just having LAPACK installed on all nodes, see https://spark.apache.org/docs/1.1.0/mllib-guide.htm…

Cheers, this was interesting. I think my 'try spark' button would get pushed if I had to do a big job using a standard method for a company e.g. some massive GLM.

Re: Static, Ahead of Time Compiled Julia

#85

Post by conjectures »

acidflask wrote: post #56
lmm wrote: post #45

Earlier quoted context omitted.

> I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box. Did you look at MLlib and/or just using Breeze directly? There's a bit of awkwardness in the initial set up of the cluster (mainly just having LAPACK installed on all nodes, see https://spark.apache.org/docs/1.1.0/mllib-guide.htm…

Most people don't need more than a handful of linear algebra operations (or think they don't), so Breeze and most wrappers of LAPACK or similar libraries don't implement or wrap them. But most people who work seriously on numerical routines will quickly run into performance problems if all they do is call LAPACK routines for general matrices instead of taking advantage of matrix structure. I have yet to come across a…

+1 this kind of issue is why I went for Julia - the support for lin alg (including with CUDA) is very good indeed.

The other issue being that Julia gives fine grained control over a cluster in a way something more abstract couldn't. (After cobbling together a scripting-style map reducer based on the default functionality - ClusterUtils.jl.)

Re: Static, Ahead of Time Compiled Julia

#86

Post by nickpsecurity »

vanderZwan wrote: post #83
StefanKarpinski wrote: post #74

Earlier quoted context omitted.

The parser and some lowering passes are still written in femtolisp. There has been some discussion of switching to the native JuliaParser package [1]. However, JuliaParser doesn't implement the fairly tricky lowering passes that the femtolisp parser does. I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the pars…

> I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the parsing and lowering will be converted to C instead. But isn't Julia supposed to be fast? ;)

And this is just a parser. Nothing too fancy. Analysis should be able to produce some efficient code for one.

Re: Static, Ahead of Time Compiled Julia

#87

Post by ChrisFoster »

StefanKarpinski wrote: post #41
ChrisFoster wrote: post #33

Earlier quoted context omitted.

I'm an enthusiastic julia user, observer and very minor contributor. IMO a lot of the issues in this constructive rant have been addressed to some extent. For context, here's the previous HN discussion https://news.ycombinator.com/item?id=8809422 Going through the post in order: The stable releases still have some bugs as you would expect in a young language, but 0.4 is now well below my tolerance level. For a rough…

> I've no idea about the "private and semi-private communications" and I can only hope things were patched up there. I'm the co-creator that Dan was talking about. He wrote a bunch of less-than-charitable comments on the aforementioned semi-private forum – not specifically to me, but where he surely knew I would read them – to which I responded with: https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11 You ca…

Thanks for the link. After reading the extra context Dan's comment about the community is only more baffling than before. To me your response seems about as measured and straight forwardly honest as it could be, with a double dose of constructive investigation on the purely technical matters.
Post reply on HN