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

131–140 of 211 posts

Re: The Julia Programming Language

#131

Post by pwang »

fijal wrote: post #39
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…

Python+numpy+scipy does work only if you actually don't write much python or at least not run much python. Otherwise it sucks

> Otherwise it sucks

Seriously? I mean, I know you are very excited about your work on PyPy, but why do you have to go around saying baseless stuff like this? There are many, many thousands of people who write lots of Python code every day that rely on Numpy, Scipy, and Matplotlib to get their work done, and who seem to be quite pleased with it. There is a lot of work left to do on all parts of that stack, but that's a far cry from "it sucks".

Re: The Julia Programming Language

#132

Post by samth »

tomp wrote: post #59
samth wrote: post #25

Earlier quoted context omitted.

It's great the metaprogramming support seems to be a requirement for new languages these days. Unfortunately, this one combines the inconvenience of Template Haskell (explicit invocation of macros with @) and the bugs of Common Lisp (the section on hygiene says, basically, "we have gensym"). Fortunately, the language is young, and I hope they can improve this story.

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.

Re: The Julia Programming Language

#133

Post by sparky »

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.

Re: The Julia Programming Language

#134

Post by StefanKarpinski »

warmfuzzykitten wrote: post #102
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…

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 — but that's syntactically sketchy since both are valid by themselves. It makes parsing a complete nightmare — both for machines and, to a lesser extent, people. I wouldn't be completely averse to indentation-based blocking, but I'm not really a huge fan of it either. I'm cool with the way both Matlab and Ruby do it, which is using `end`. Could conceivably change, but relatively trivial syntactic alterations like this are a really low priority. What we have now works well and is familiar to both Ruby and Matlab programmers.

Re: The Julia Programming Language

#135

Post by StefanKarpinski »

dkarl wrote: post #127
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.

As a compromise, I think it would be helpful to be able to define structs that have a known layout in memory but no dynamic identity. They would be treated like primitive types in Java, but with the crucial difference that users could define their own. That way users could write Julia code that stores and accesses data in the same format they need for interoperating with whatever native libraries they use, instead of…

We've discussed our way down that path but the design ends up being unsatisfying because "objects" and "structs" end up being so similar yet different. It may be what we have to do, but I haven't given up yet on having structs and Julia composite types be compatible somehow. pron's scheme is interesting.

Re: The Julia Programming Language

#136

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…

This is an interesting scheme and seems like it might work, but I'm not sure. Would you be willing to pop onto julia-dev@googlegroups.com and post this suggestion there so we can have a full-blown discussion of it? Hard to do here — and some of the other developers would need to chime in on this too.

Re: The Julia Programming Language

#137

Post by StefanKarpinski »

wbhart wrote: post #123
StefanKarpinski wrote: post #94

Earlier quoted context omitted.

If you happened to feel like trying to port it to Julia, it would be fairly doable. All the low-level functionality is there to allow it — bit twiddling operations, growable dense arrays of integers, etc.

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.

Re: The Julia Programming Language

#138

Post by teoliphant »

fijal wrote: post #39
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…

Python+numpy+scipy does work only if you actually don't write much python or at least not run much python. Otherwise it sucks

Nice, Fijal. It's good that I can count on you for un-biased opinions.

Re: The Julia Programming Language

#139

Post by andrewcooke »

a bit late to the party here, but i see no-one has mentioned gpus. since julia supports calling c libraries i guess this will work, but i wondered if anyone knew of any work on closer integration?

(also, julia is not a great name for googling....)

Re: The Julia Programming Language

#140

Post by StefanKarpinski »

Peaker wrote: post #128
StefanKarpinski wrote: post #74

Earlier quoted context omitted.

At first we were going to use 0-based indexing, but it made porting any Matlab code over very hard, which defeats a large part of the purpose of having Matlab-like syntax in the first place — to leverage the large amount of Matlab code and expertise that exists out there. However, as I've used it more and more, 1-based indexing has really grown on me. I feel like I make far fewer off-by-one errors and actually hardly…

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 often times when I'm doing libraryish internals code, whereas the former are more common when I'm doing high level userish code.
Post reply on HN