Hacker News Reader

Comment by cjfont | Hacker News Reader

> 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 a piece of code is about as important to me as the "expressiveness" of a catalytic converter.

You want a fast car, but don't care much for having an aerodynamic design, hmmm..

EDIT: In retrospect I now think he means he wants to be able to create the project fast, and this is not about performance.

View on HN

This is a confusing rebuttal, because cars have an aerodynamic design primarily for performance reasons, and Evan is very clear in this article that his primary concern is performance. I think you've misread him.

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

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.

I don't know if this an argument for or against static typing and type safety but there are two sides to this coin.

In dynamic programming languages it is definitely easy to get shit done, at least initially.

However as a project progresses to the point where a lot of refactoring takes place and there's more than a handful of people working on it, a good static typing language will make sure that shit keeps on getting done and things won't break due to a subtle typing error. Things will be caught by the compiler even before you get running the test suite.

I agree.

In other words, automatic program-correctness check is a crucial feature if project goes larger. And type check is actually one of the simplest, easiest and fastest way to archive that.

But most dynamic languages doesn't provide type-check. Really sad.

Adding type annotation on dynamic language is a kind of best mix of two worlds, and Julia seems pushing this approach even further - JIT static types from type annotation.

That's a strong vs. weak issue, not a static vs dynamic issue.

  irb(main):001:0> 1 + "hello"
  TypeError: String can't be coerced into Fixnum
          from (irb):1:in `+'
          from (irb):1
          from /usr/bin/irb:12:in `<main>'

Static prevents type errors from propagating, which is particularly important when using generic functions. In ruby you can have a type error four functions back pass silently until you do something ungeneric with it, which makes debugging harder than it should be.

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

Virtually every optimization even dynamic languages make are about narrowing down exactly what the type something is and which method that is called at runtime. At that point you can do things like inlining and other high powered optimizations.

But that allows for smarter optimizations.

Of course it does, and I never said it didn't. I just said that my impression is that the primary motivation of language people is correctness. However, I have published several in the area of software verification, so perhaps I am biased.

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

He's saying that he wants both: fast design and fast performance.

I think what he means is that 'safety, type systems, homoiconicity...' may or may not be important, but he's more worried about the end result.

So if other people want to work on those things, good for them. He's going to be working on his own stuff.

This is about the ability to complete a project fast, which is typically about both convenience of fast prototyping, and performance (ie. you don't want to wait days for the results to be computed before changing something in the code, and you want that change to be easy).

And probably few buyers who want fast cars care about aerodynamic design per se -- they care about speed; sure, if better aerodynamics is what's necessary then so be it, but they would also prefer a fast car with poor aerodynamics and a huge engine to the very aerodynamic and fuel efficient, but slow one.

As is usually the case with language design, performance and optimization are often on the opposite side of the scale from code learn-ability and usability. More than likely, the "huge engine" would be some other burden the language has that he doesn't want in exchange for faster prototyping.

I'd actually say both Julia and Matlab are often quite decent on both learnability, usability (at least for their purpose -- especially as the library for Julia develops), and performance. Certainly, on par with other newly-designed languages. Sure, you can go faster with Fortran, but you can do that when you see that it is really needed...

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.

Reply on news.ycombinator.com