Live data from Hacker News

Why I'm Betting On Julia

evanmiller.org

41–50 of 258 posts

Re: Why I'm Betting On Julia

#41
post #4

This sounds like premature-optimization to me. Maybe it's just me, but in the apps I write in dynamic languages, the bottleneck is rarely in the language. It's usually in some IO. EDIT: some sentence in the article gave me the impression he was using this for non-math-heavy stuff which is why I said this

In production code paths yes, but I have to admit that the 3 seconds it takes a bare Rails environment to start up has over time made me really pine for a Go or Haskell project. Rapid prototyping is great, but responsiveness at the command line also is another form of rapidity that also serves developer productivity in appealing ways (auto testing harnesses for instance).

Re: Why I'm Betting On Julia

#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 inevitable complexity that arises when building systems in a maintainable way.

[1]http://www.paulgraham.com/avg.html

Re: Why I'm Betting On Julia

#43
post #25

Earlier quoted context omitted.

Some people build software as a product, for example SaaS companies, software vendors, or enterprise systems programmers. Then some build software to automate difficult tasks or to interact with data. I think the first group cares deeply (or at least should) about maintainability, the second group just wants it to work and work fast. If it's easy to update and fix later that's a bonus but not the main point. I fall i…

Also a lot of scientific computing things are very much it works or it doesn't, and once it does it is a reification of some fundamental mathematical algorithm: a black box that should never need to be opened again.

Which is terrible science. Job #1 of good science is reproducability. Crapping out black boxes and claiming "I've proven my theory" in a way no-one else can analyse or reproduce undermines the fundamentals of the scientific method.

Re: Why I'm Betting On Julia

#44
post #31
post #15

Earlier quoted context omitted.

And yet he doesn't care about type systems, which are largely implemented to help with optimization, you see.

Really? My impression is that it's largely correctness.

There are plenty of optimizations that are only available when you know the types of the objects you're dealing with (mostly relating to aliasing). See:

http://scholarworks.umass.edu/cgi/viewcontent.cgi?article=10...

Re: Why I'm Betting On Julia

#45
post #40

Earlier quoted context omitted.

That's arguable - I hear more people talking about how types reduce bugs in code than how it improves performance. Besides, that's one of the three examples he mentioned, and the the other two are not features involved with said optimisation.

Well, it certainly optimises my ability to get shit done if I don't waste it on subtle type-conversion debugging.

Hah! Agreed.

Re: Why I'm Betting On Julia

#47
post #13
post #6

> 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, but when I'm messing around with a new project for fun, my two concerns are 1) making it work and 2) making it fast. For me, code is like a car. It's a means to an end. The "expressiveness" of…

It's more like he wants a fast car but doesn't want to deal with servicing it. So it might fall apart in six months, but that's something he is OK with.

Without presuming to speak for Evan --

Julia's target audience is technical computing, and a large fraction of software in this space is built to solve a particular problem that only might matter for 6 months or a year. You might be trying to simulate the behavior of an experiment you just designed, for example, or trying to analyze a very specific property of a data set. These codes are often very tightly coupled to the scientific problem, and are only ever used in the context of a particular short-lived project. You do the experiments, write the paper, and move on with your life.

To be clear, I don't think Julia itself encourages this pattern any more or less than another language. But it's a very common pattern for scientists, so they often don't care about long-term maintainability.

Granted, this sometimes comes back to bite them later, if they discover the old code is good for a newer experiment, or they need to go back and re-validate results. But this doesn't always happen, and it's not like they're running a live service with customers -- when they finish a given paper, it's actually not unlikely that no one will ever need to use that software again. It's not easy to argue that they should care about maintainability when there's a decent chance this is one-off code.

Re: Why I'm Betting On Julia

#48
When out with friends recently, one of them mentioned how awesome Julia is. I was surprised to hear someone talk about it, even from another person in science. She turned and gushed about how awesome it was, how supportive the community was, even though she was "not really someone who likes programming." And she liked it so much she was telling her friends about it at a bar!

If you make a programming language that people who don't like programming love enough to spread by word of mouth when not near a computer, which technically-oriented people also love, that's a lot like the OSX terminal + nice GUI blend.

That's a pretty rare thing. And for collaborative science it's pretty important. Often, you'll have people in a bio lab who are very proficient in their area of biological expertise, but who would be solving the wrong problem by spending 2 years trying to become C++ hackers. On the other hand, there are a lot of people who write computational libraries, but know they have to translate them to matlab, or write a matlab wrapper and pray that their users can get it to compile which might sound simple to folks here, but is really frustrating for less computationally oriented people when something goes wrong.

Re: Why I'm Betting On Julia

#49
The author and I like Julia for nearly opposite reasons. (I write Julia for the language geek reasons. The power of homoiconicity is amazing for writing static analysis in the language you're analyzing.) It's really cool that Julia can appeal to people with nearly opposing priorities tho. :)

I'm looking forward to giving the workshop at UChicago. It'll be my third time presenting an Intro to Julia workshop.

Re: Why I'm Betting On Julia

#50

When out with friends recently, one of them mentioned how awesome Julia is. I was surprised to hear someone talk about it, even from another person in science. She turned and gushed about how awesome it was, how supportive the community was, even though she was "not really someone who likes programming." And she liked it so much she was telling her friends about it at a bar! If you make a programming language that pe…

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?
Post reply on HN