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

141–150 of 211 posts

Re: The Julia Programming Language

#141

Post by StefanKarpinski »

sparky wrote: post #133

Would be interesting to see how Julia perf compares to C++ compiled or JITed with LLVM via G++ 4.6+Dragonegg or Clang 3.0/svn. Would be more apples-to-apples, since both would use the same middle- and back-end. G++ 4.2.1 is a bit obsolete at this point, but as it probably came by default on the MBP they tested on, it's understandable.

That would certainly be doable. If the performance is better, we can certainly switch to using that for our benchmarks. The idea for the benchmarks is to compare to a "gold standard" — hence the fact that the best results are taken across all optimization levels. We could even take the best results across multiple C compilers to give ourselves the absolute hardest comparison :-)

Re: The Julia Programming Language

#142

Post by blacksqr »

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?

Re: The Julia Programming Language

#143

Post by nu23 »

StefanKarpinski wrote: post #73
tomp wrote: post #59

Earlier quoted context omitted.

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…

Someone already mentioned PLOT. This would be a good thing to lookup when designing your hygienic macro system, http://users.rcn.com/david-moon/PLOT/index.html. The author was also involved in Dylan, which is another infix language with hygienic macros.

Re: The Julia Programming Language

#144

Post by StefanKarpinski »

tomp wrote: post #90
StefanKarpinski wrote: post #73

Earlier quoted context omitted.

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…

Just a comment/suggestion: could someone with GitHub write access go over your wiki and fix code samples where multiple lines have been concatenated into a single line? E.g. https://github.com/JuliaLang/julia/wiki/Types-and-their-repr... , heading `Built-in types`.

We've actually switched the documentation over to the main website: http://julialang.org/manual/. The website is hosted on GitHub using Jekyll: https://github.com/JuliaLang/julialang.github.com. As a side-effect, you can edit the docs and create pull requests, which you can't do on GitHub wikis.

Re: The Julia Programming Language

#145

Post by StefanKarpinski »

tomp wrote: post #90
StefanKarpinski wrote: post #73

Earlier quoted context omitted.

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…

Just a comment/suggestion: could someone with GitHub write access go over your wiki and fix code samples where multiple lines have been concatenated into a single line? E.g. https://github.com/JuliaLang/julia/wiki/Types-and-their-repr... , heading `Built-in types`.

Oh, also I believe the link was probably too stale docs. They're gone now. What's on the website is mostly up-to-date, but a few things have changed and will need fixing.

Re: The Julia Programming Language

#146

Post by StefanKarpinski »

wes-exp wrote: post #82
StefanKarpinski wrote: post #73

Earlier quoted context omitted.

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…

Seems like there have been a variety of attempts to introduce lisp-style macros into non-lisp languages that use traditional syntax rather than s-expressions. I can see how this can succeed for simple macros without sacrificing much. However, complex macros done this way tend to be much more complicated than the equivalent lisp code. Do you believe that Julia solves this problem, or is it also subject to some of the…

Constructing and manipulating code in Julia is a bit more complicated than Lisp — because Lisp lists are so damned simple. However, not by much. I think most of the complexity of code that generates code is inherent. Sometimes being that meta just makes your brain hurt. Our printf implementation (https://github.com/JuliaLang/julia/blob/master/j/printf.j) is about as bad as it gets and it's still pretty understandable — aside from the inherent complexity of implementing printf and the separation of what's computed at compile time and what's computed at run time.

Re: The Julia Programming Language

#147

Post by StefanKarpinski »

samth wrote: post #132
tomp wrote: post #59

Earlier quoted context omitted.

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.

The problem with this is that it limits the options of library writers. For example, I can't replace some function with a macro that does something smart, such as check format strings for printf at compile time, because that breaks all callers. It also fundamentally limits what you can build with macros, because you can't build language features that are basic -- they always appear tacked-on.

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 you know exactly what's going on. It also means you can't do stuff like try to pass a macro as an argument to a higher-order function — what does that even do? I.e. what does map(m,vec) mean where m is a macro?

Re: The Julia Programming Language

#148

Post by StefanKarpinski »

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

Sorry! The only thing I can say in our defense is that this is pretty trivial compared to installing a lot of scientific computing packages. But seriously, we'd like a drag-and-drop Mac installer. Anyone want to do that? (Only half kidding.)

Stepping back a bit, this is one of the reasons why having an entirely web-based experience is appealing — then you can let people use a known-good setup without needing to mess around with installing a fairly extensive amount of software just to get basic things to work. Then there's also the general appeal of doing big data work a la Google docs or Gmail. The trick is getting the user experience to be good enough on the web.

Re: The Julia Programming Language

#149

Post by StefanKarpinski »

pron wrote: post #98
ViralBShah wrote: post #92

Earlier quoted context omitted.

Yes, I pretty much had the same thought, but then I started thinking about multiple dispatch, calling C/Fortran libraries, polyhedral optimizations, and I realized that V8 developers may not have the same design targets in mind.

... and the JVM (HotSpot) is even better than V8.

I feel like V8 faces a harder problem and has solved it ingeniously. Not to knock HotSpot, which is excellent and keeps getting better — it just seems like making the JVM go fast is not as hard as making something like JavaScript go fast. It's a tough comparison; kind of apples to oranges.

Re: The Julia Programming Language

#150

Post by StefanKarpinski »

pron wrote: post #111
StefanKarpinski wrote: post #78

Earlier quoted context omitted.

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

I don't know if I'd call it duck-typing when methods are not grouped into interfaces. I think you could say that in Julia, each method is an interface. I find it much cleaner than actual "duck-typing" (the way it's done in , say, Scala with structural types) because then you have both an interface, which specifies a contract, as well as the method name, which also specifies a contract when duck-typing is used, even w…

It's been discussed, and would be satisfying to have an `Iterable` abstract type and ensure that every object implements `Iterable` satisfies contract of having appropriate `start`, `done` and `next` methods, but that requires two features we don't have yet: multiple inheritance of abstract types, and some way of specifying an interface. There's been some discussion of this, and I believe we have the way multiple inheritance could work mostly worked out; enforcement of interface implementation, not so much. However, it's a pretty massive undertaking to add it to the language. Quick teaser: generic functions and final concrete types actually make multiple dispatch work a lot better than it does with single dispatch and the "bag of named methods inside an object" model of traditional OO.

So far we haven't actually felt a "pressing need" for multiple inheritance or interfaces, and we tend to take a pressing-need approach to language features. If you can live without a feature for a while, then maybe you really didn't need it in the first place. But we'll have to see what happens when other people are starting to try to use if for things.

Aren't compound types inherently concrete? The compoundness describes the implementation of the type, implying that it must have an implementation, hence must be concrete.

Post reply on HN