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

Why I'm Betting On Julia

evanmiller.org

Post reply on HN
Print view View original

141–150 of 258 posts

Re: Why I'm Betting On Julia

#141

Post by john_b »

evanspa wrote: post #42

When I read the opening paragraph, I immediately thought of the author as a Blub programmer [1]. "The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth. I'm sure these things are great..." Yes, those things are great. They ultimately aid in helping the programmer tackle the inevita…

You're assuming the author wants to use Julia to build complex systems. Much of scientific computing has no need to do so, but is more concerned with discovering new knowledge and testing new ideas. Once the knowledge is gained, products may be built around that knowledge or new inquirires may be launched from it, but scientific computing usually uses programming languages as research tools rather than development tools.

Re: Why I'm Betting On Julia

#142

Post by Blahah »

howeman wrote: post #98
Blahah wrote: post #58

Just yesterday I decided to start seriously developing in Julia. High-level languages are a bottleneck for computational biology. We need to be able to write things fast, and have them run fast. So far no language really does this. But Julia looks like the one. I'm going to put together a BioJulia team is anyone is interested in playing.

You might also look at biogo for inspiration https://code.google.com/p/biogo/

I had BioPython, BioRuby, BioPerl and BioJava on the list - hadn't thought of BioGo! Thanks.

Re: Why I'm Betting On Julia

#143

Post by kldavenport »

simonster wrote: post #77
Pxtl wrote: post #50

Earlier quoted context omitted.

To be fair, there's also Python+NumPy and R in that space, not just Matlab. Besides the "tinker with LLVM" thing, what does Julia offer that Python (or Cython for speed)+NumPy does not?

Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R. Julia is…

Check out the Python JIT compiler NUMBA. It compiles annotated Python and NumPy code to LLVM (through decorators). It's been wicked fast for my use cases: http://numba.pydata.org/

Re: Why I'm Betting On Julia

#144

Post by Homunculiheaded »

haberman wrote: post #117

Can Julia be a competitor to R? I love R in concept (interactive environment for statistical analysis) but the language just drives me crazy in its multitude of types and the loosey-goosey ways it converts between them. A friend of mine is really proficient with R; when I walked him through some of the R patterns that are very confusing/irregular to me, he sort of laughed: he could see what I was saying but he said "…

The biggest thing that R has is just an incredible amount of really well documented packages, that are quite frequently cutting edge (unless you want to do any deep learning work). Not to mention that the base R has just a tremendous amount of useful stuff baked in.

I've kept an eye on Julia and would love to use it in my everyday work, but also know that for now that's just not possible because of how many built-in functions and packages I rely on.

However solving this is just a function of time and community (Julia just needs their Hadley Wickham). I remember when people scoffed at Python because it has nowhere near the ecosystem that Perl did.

Re: Why I'm Betting On Julia

#145

Post by zhemao »

lafar6502 wrote: post #118

Looks strangely similar to Lua

Well, most of the syntax he shows here is just calling functions. A lot of dynamic languages have similar syntax for functions calls. But you're right that Julia's syntax is superficially similar, with function definitions like

    function foo(bar, baz)
    end
and 1-based indexing of arrays (although Julia's use of that was to be similar to MATLAB).

Re: Why I'm Betting On Julia

#147

Post by tieTYT »

lightcatcher wrote: post #106
tieTYT wrote: post #80

Earlier quoted context omitted.

IME, you only know that with hindsight. I have made one off programs I never needed to look at again. I've also made what I thought were one off programs that I needed to maintain for a while. Even in a prototype, you may need to rework a particular piece of code multiple times before it works correctly. Even with a prototype, you may need to use it as a reference for your official version. Even with a prototype, you…

> What if it isn't fast enough on your first attempt? Won't you wish your code was maintainable so you could change it to be faster? From my experience, this isn't the case at all. A lot of the time my first attempt is in Python. The first attempt is really more of a prototype or a proof of concept. If the code works and I want to productize it, the code needs to be sped up. I have (at least) 2 choices: (1) make the…

Fair enough. But you ignored/changed the foundation my reply was built on. I'm replying to TFA saying "speed is second" and maintainability is... not considered. You're talking about "correctness being first" and speed/maintainability being not considered.

Re: Why I'm Betting On Julia

#148

Post by ihnorton »

wirrbel wrote: post #101
simonster wrote: post #77

Earlier quoted context omitted.

Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R. Julia is…

To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awk…

> Julia will lack enough libraries, especially on the unscientific part (GUI, databases, network, all the other stuff you need).

Yes, but this is rapidly improving. Julia has Gtk bindings that have seen a lot of improvement over the past two months. There are ODBC and SQLite interfaces, a MySQL interface is in progress, and probably others.

Julia has the advantage that you can write fast bindings in pure Julia, which alleviates the extra cognitive and tooling overhead of writing extensions in C.

Building a language ecosystem is a bit of a ponzi scheme - but it has real potential for a great payoff at the end!

Re: Why I'm Betting On Julia

#149

Post by astrieanna »

farslan wrote: post #138

We have a Julia and iJulia app on https://koding.com . It's going to be used by Harvard & MIT students soon. It's public and everyone can try it by simple login to Koding. The best part is you can easily try it online, without installing anything. Here is an screenshot of how it's look like (iJulia and Julia inside Terminal): http://d.pr/i/MsZt The source of this app can be found here: https://github.com/gokmen/julia…

You can also use Julia on the Sage Math Cloud. https://cloud.sagemath.com/

They don't have IJulia (yet) though.

Re: Why I'm Betting On Julia

#150

Post by wirrbel »

StefanKarpinski wrote: post #112
wirrbel wrote: post #101

Earlier quoted context omitted.

To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awk…

> That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpy's solution is as good as introducing two different operators The thing is that the multiplication operation for matrices is matrix multiplication, not elementwise multiplication. When you apply a polynomial like x^2 + y to matrices, you do not want to apply the polynomi…

If you are doing linear algebra, I agree. Yet linear algebra is not the only thing I want to do with numbers. I think most of the time I do use the elementwise operation, such as:

    x = linspace(0,10, 1000)
    y = (x
Of course I can just use matrices and then I have the information at hand that I am doing linear algebra right now:

    x = matrix([[3, 0],
                [9, 5]])

    Out[28]: 
    matrix([[ 9,  0],
            [72, 25]])

    x**2 + x
I think this is not too much boilerplate and gives nice semantic information within the sourcecode. However, if you want to perform this with a 2d array object, you can also use its dot method:

    In [ 1]: a
    Out[ 1]: 
    array([[ 9,  0],
           [72, 25]])

    In [ 2]: a.dot(a)
    Out[ 2]: 
    array([[  81,    0],
           [2448,  625]])

    In [ 3]: a * a
    Out[ 3]: 
    array([[  81,    0],
           [5184,  625]])
The approach of the matrix object nicely takes into account that operands of a "normal" multiplication `*` commute, so the elementwise multiplication fits the picture here. Wheres matrix multiplication - which is non-associative for most matrices - is performed by a different method.
Post reply on HN