Live data from Hacker News

Why Julia

ucidatascienceinitiative.github.io

151–160 of 257 posts

Re: Why Julia

#151

Earlier quoted context omitted.

> and python (a sane, real programming language) So... R is an unreal language then?

Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming. Because of the re-implementation o…

> Nah, it's just a re-implementation of S, which was really, really old and different from what people expect.

Was S "really, really old" when it was re-implemented in R? Gentleman and Ihaka first announced R in 1993 (26 years ago!).

The development of S started in 1976 (i.e. 17 years before R was first released). R was a implementation of S3, "the New S language", which was a major rewrite done in 1988 (it was just five years old when R was announced!).

Re: Why Julia

#152

Earlier quoted context omitted.

Agreed, that's my experience as well. Julia is amazing for scripts and smaller projects, but I wish there was something like Swift (which I'm increasingly convinced is closest to the ultimate general-purpose language) with all the nice things that Julia has. Specifically, these things make Julia less suitable for larger projects: - Lack of support for OOP. And no, purely functional programming is not the best way to…

> - Lack of support for OOP. And no, purely functional programming is not the best way to code all projects. Julia doesn't rely on functional programming and there are also structs and operator overloading. What feature do you think is missing specifically? > Dynamic typing. Julia is not dynamically typed, though if you write a type unstable function, you will get back an Any type. - Module system doesn't seem to be…

Julia is dynamically typed: https://stackoverflow.com/a/28096079.

Re: Why Julia

#153

Earlier quoted context omitted.

If you're going to give a counterexample, please give it. I thought about my post after I read it and came to this- given Djikstra's (only system which can describe an empty interval and interval with first element without "unnaturals" ) and (?)'s argument that it creates a nice homomorphism between real-number intervals and integer slices then it's inarguable to me that 0-based is more mathematically elegant. Where…

Why? You've already come to the conclusion that anybody that disagrees with you is an idiot, and you think your argument is fully reasoned and covers all bases. Why should I believe that you would change your mind given new information?

I guess, because often you're not arguing in order to convince your opponent, you're arguing to sway the crowd (and sometimes, decide yourself).

And I don't think they're idiots, I just think that they're wrong. Not many people have read Djikstra and (?) and have deep faith in mathematical beauty, or have even thought about this much, doesn't make them idiots.

Re: Why Julia

#154

Earlier quoted context omitted.

honest question, not a serious SDE here. In what ways is julia not supportive of OOP?

It doesn't have interfaces for example. It doesn't have access modifiers. Also, not sure if this belongs to OOP but working with optionals is cumbersome.

Python also doesn’t have interfaces or access modifiers. Would you consider Python to have bad support for OOP by those criteria?

Re: Why Julia

#155
post #99

Earlier quoted context omitted.

Multiple dispatch has to be coded by hand in Python, it isn’t a feature of the language.

Python 3.7 added the ability to use type annotations with the @functools.singledispatch decorator which lets you write functions in a multi-dispatch manner.

As the name suggests, that lets you write functions in a single-dispatch manner. That is different from multiple-dispatch.

Re: Why Julia

#156

Earlier quoted context omitted.

Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming. Because of the re-implementation o…

Wise words here. In my humble opinion, applying S's syntactic sugar on top of Scheme-forged core did more bad than good to R. Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible. As for the two approaches to solving problems (TIMTOWTDI vs Python's "one true way") I think that's a matter of personal preference; I, personally, appreciate the freedom that R gives me. Also, it mig…

> Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible.

On the other hand, if it was not for that compatibility with S we would not be having this conversation: R would be just a footnote in the history of statistical computing like Lisp-Stat.

Re: Why Julia

#157

Earlier quoted context omitted.

You have to use it inside a REPL, like R or Matlab. Julia using LLVM and compiling on-the-fly is not sloppy design, it's a design tradeoff (and a great one, if you really need speed). Julia is not a scripting language, it's a language for mathematical analysis. Also going back to your example the solution would be to use ImageMagick.jl from Julia, and extend the library (4 extra lines with ccall) if it's not availabl…

> Julia is not a scripting language, it's a language for mathematical analysis. Ok, this clarifies the matter a lot. So julia is not intended to be a general-purpose programming language. Are you involved in julia development? (Besides, I strongly dislike the design tradeoff of not being a good unix citizen.)

I'm not a Julia developer, but the great thing with Julia is that the libraries are exceptionally easy to read and extend, because the core developers make a strong effort to write clean code. Just look at ImageMagick.jl and you'll see, but I have the same experience with other libraries as well.

Also the language itself supports extending code (multiple dispatch really helps it to stay clean).

Re: Why Julia

#158

I wish Julia would be more strict wrt type coercion of integer to float values. I've once spent a day debugging the issue caused by the following line of code, where t1, t2 are floats and v is an array: d = (t2 - t1) * length(v) It should've been LinearAlgebra.norm():Float instead of length():Int. Had julia been stricter the code would have failed to run, saving me much time.

I actually can't think of a single language that doesn't allow you to multiply an integer and a floating point value, yielding a floating point result.

Re: Why Julia

#159
post #138

Earlier quoted context omitted.

GP wrote (emphasis mine) 'For "2D indexing" into a 1D array '. I presume it's some graphics-related optimization or some pointer arithmetics-related work, but I'd also be curious about some concrete use-cases too.

Julia n-D arrays are stored contiguously in memory. So, you can access the memory by reshaping the array into whatever dimension you want and then access it using the A[i,j,k] syntax.

What does reshape actually do? Create a 1-D array from a 2-D one or vice versa, or just make appear to be so?

Re: Why Julia

#160
I didn't know about the Unicode tab completion. I gave it a whirl on the cli and loved it. Then I tried it out in julia-mode in Emacs, and it works there too! What other editors support this?
Post reply on HN