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

111–120 of 258 posts

Re: Why I'm Betting On Julia

#111

Post by simonster »

exDM69 wrote: post #93
shele wrote: post #27

"Julia was not designed by language geeks — it came from math, science, and engineering MIT students" This statement is built on a false dichotomy. And it is not really true for Julia, take the type system for example, sophisticated AND unintrusive.

> "Julia was not designed by language geeks — it came from math, science, and engineering MIT students" This makes me a bit cautious about the language. Scientific computing people are often very smart but they are not programmers or computer scientists and may do funny things that a computer scientist would not. Like one based indexing of arrays in Julia. This is not a big deal but I'm a bit wary that there may be s…

> Another example is the byte addressing of UTF-8 strings, which may give an error if you try to index strings in the middle of a UTF-8 sequence [1]. s = "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second character of the string. I find this a little awkward.

Yes, it's a little awkward, but to understand why this tradeoff was made, think about how you'd get the nth character in a UTF-8 string. There is a tradeoff between intuitive O(n) string indexing by characters and O(1) string indexing by bytes.

The way out that some programming languages have chosen is to store your strings as UTF-16, and use O(1) indexing by two-byte sequence. That's not a great solution, because 1) it takes twice as much memory to store an ASCII string and 2) if someone gives you a string that contains a Unicode character that can't be expressed in UCS-2, like 🐣, your code will either be unable to handle it at all or do the wrong thing, and you are unlikely to know that until it happens.

The other way out is to store all of your strings as UTF-32/UCS-4. I'm not sure any programming language does this, because using 4x as much memory for ASCII strings and making string manipulation significantly slower as a result (particularly for medium-sized strings that would have fit in L1 cache as UTF-8 but can't as UCS-4) is not really a great design decision.

Instead of O(n) string indexing by characters, Julia has fast string indexing by bytes with chr2ind and nextind functions to get byte indexes by character index, and iterating over strings gives 4-byte characters. Is this the appropriate tradeoff? That depends on your taste. But I don't think that additional computer science knowledge would have made this problem any easier.

Re: Why I'm Betting On Julia

#112

Post by StefanKarpinski »

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…

> 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 polynomial elementwise – you want to square the x matrix and add the y matrix to it.

Re: Why I'm Betting On Julia

#113

Post by nbouscal »

dantiberian wrote: post #108
nbouscal wrote: post #81

Earlier quoted context omitted.

I'm glad I'm not the only one. I couldn't make it past the first paragraph. He says he doesn't care for safety and type systems, and then says what he cares about is making it work and making it fast, both of which are significantly aided by safety and type systems.

All he's saying is he doesn't care about the features, just what they let him do with them. Type safety in and of itself isn't interesting to the author but he appreciates it's benefits.

If that's the case, the author would be well-served by rewriting the first paragraph to make that clear. The way it's currently written does not communicate that to me at all.

Re: Why I'm Betting On Julia

#114

Post by [deleted] »

candybar wrote: post #71

I really don't like the anti-intellectual tone of the beginning. "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." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

[deleted]

Re: Why I'm Betting On Julia

#115

Post by ahuth »

candybar wrote: post #71

I really don't like the anti-intellectual tone of the beginning. "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." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

I didn't pick up an anti-intellectual tone.

His point is the same way I feel: stuff like type systems and homoiconicity (I don't even know what that means) don't interest me. I'd rather think about the work that I'm doing.

Also, these things are a step or two above my level of understanding (but probably not the op's).

I do care about security, thread safety, modularity, etc... but I can't really contribute to the debate about how we get there.

Re: Why I'm Betting On Julia

#116

Post by avodonosov »

The reason to bet on Julia is disassembling a function? This is a standard feature in Common Lisp (ANSI standardized in 1994)

  CL-USER> (defun f(x) (* x x))
  F
  CL-USER> (disassemble 'f)
  L0
           (leaq (@ (:^ L0) (% rip)) (% fn))       ;     [0]
           (cmpl ($ 8) (% nargs))                  ;     [7]
           (jne L33)                               ;    [10]
           (pushq (% rbp))                         ;    [12]
           (movq (% rsp) (% rbp))                  ;    [13]
           (pushq (% arg_z))                       ;    [16]
           (movq (% arg_z) (% arg_y))              ;    [17]
           (leaveq)                                ;    [20]
           (jmpq (@ .SPBUILTIN-TIMES))             ;    [21]
  L33
           (uuo-error-wrong-number-of-args)        ;    [33]

Re: Why I'm Betting On Julia

#117

Post by haberman »

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 "with R you can't worry about things too much, you kind of just have to just go with it."

If Julia can serve some of the same use cases but in a better-designed way, sign me up!

Re: Why I'm Betting On Julia

#119

Post by ahuth »

nbouscal wrote: post #81
candybar wrote: post #71

I really don't like the anti-intellectual tone of the beginning. "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." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

I'm glad I'm not the only one. I couldn't make it past the first paragraph. He says he doesn't care for safety and type systems, and then says what he cares about is making it work and making it fast, both of which are significantly aided by safety and type systems.

Safety/type systems may significantly aid making it work/fast, but the end result is more important to him than more abstract concepts.

Some people are really interested in making compilers, right? While others (such as me) just want to do cool things with them.

Re: Why I'm Betting On Julia

#120

Post by xixi77 »

candybar wrote: post #71

I really don't like the anti-intellectual tone of the beginning. "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." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

His point is: while these things can be nice, no one cares about them other than language designer. They are only means to an end, which is user experience. Sure, some car buyers may know or care what alloy their cylinder block is made of, but a lot don't know, and don't care, how many cylinders there are. They only care (somewhat) about how it drives. And it is certainly possible to have a language with all the theoretically nice features, but offering horrible user experience for a specific purpose. Part of it is just marketing, but part of it is also optimization with a different purpose in mind.

For example, his purpose, and Julia's main use case, is often different from that of either a language designer or a software engineer: e.g. performance and fast prototyping are first order concerns (together with a decent scientific library), and everything else, like longevity, ability of future code reuse, or simplifying work of teams are way, way down the list. The reason of course is that ~90% of code is written by one person, for himself, to effectively run once and produce one paper, and to be never touched by anyone ever again. At least, this is what I see in my field, which is largely dominated by Matlab (and Matlab-like syntax is definitely a huge asset here).

Post reply on HN