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

Julia 1.0

julialang.org

Post reply on HN
Print view View original

261–270 of 446 posts

Re: Julia 1.0

#261

Post by celrod »

mikec3010 wrote: post #233
ur-whale wrote: post #196

Earlier quoted context omitted.

Again assuming: that may be true in the place where you were educated.

You're assuming I'm wrong. Show me where kids are taught to count starting at zero.

"taught to count"

I think that is the key. "1, 2, 3. There are 3 apples." is a little easier than "0, 1, 2. There are 3 apples." Counting the first item as "1" total items leads to 1 being more natural in the same way that incrementing a pointer by 0 giving you the first element is more natural.

The former is the abstraction layer most people are more familiar with.

Re: Julia 1.0

#262

Post by disgruntledphd2 »

LittlePeter wrote: post #112
ChrisRackauckas wrote: post #105

Earlier quoted context omitted.

It was literally released today. Of course the packages don't work yet...

That makes sense. Maybe I was used to R (CRAN) where uploaded packages are actually tested against the version they declare to support.

That probably didn't happen at R 1.0.0. (Release notes: ftp://cran.r-project.org/pub/R/R-release-1.0.0.html).

More informative wikipedia page: https://en.wikipedia.org/wiki/R_(programming_language)#CRAN

That being said, R was GNU S once upon a time, so they didn't really build a new language, rather an open source clone of a popular proprietary tool. (In case it wasn't clear I both love R and am madly excited that Julia has finally hit 1.0.0).

Re: Julia 1.0

#263

Post by stellalo »

ur-whale wrote: post #90
stellalo wrote: post #81

Earlier quoted context omitted.

1-based indexing is a non-issue

It most certainly is for the vast number of folks who code in C, C++, Java, Python, etc ... It will for sure hurt adoption.

I love C and I was myself suspicious when I first tried Julia. I ended up being perfectly able to reason in terms of 1-based indices and right-inclusive ranges. I’m sure I’m no special kid :-)

Re: Julia 1.0

#264

Post by et2o »

kgwgk wrote: post #177
candhee wrote: post #119

Earlier quoted context omitted.

JuliaDB declares support for 0.6 not 1.0 - http://juliadb.org/latest/ Which package declared support for 1.0.0 and didn’t compile?

A binary package will be available in CRAN for a given platform/version only if it works (it passes all the tests). It seems that Julia lets you install a non-working package without any warning (you will probably get errors when you run it, but I guess it may also fail silently which is worse).

I was excited to try using Julia 1.0.0 today after a couple years since my last try and... couldn’t.

None of the packages work with it yet. I guess I could go find an older version, but it seems like a problem that Julia will happily allow you to install a package it isn’t compatible with. What’s the point of the Pkg system then? CRAN’s model makes a lot more sense.

Re: Julia 1.0

#267

Post by kwertzzz »

kgwgk wrote: post #177
candhee wrote: post #119

Earlier quoted context omitted.

JuliaDB declares support for 0.6 not 1.0 - http://juliadb.org/latest/ Which package declared support for 1.0.0 and didn’t compile?

A binary package will be available in CRAN for a given platform/version only if it works (it passes all the tests). It seems that Julia lets you install a non-working package without any warning (you will probably get errors when you run it, but I guess it may also fail silently which is worse).

This is indeed a very good idea. In Julia, the package author defines the range of supported Julia version. Most package actually just say "version 0.6 or later". The JuliaDB package was just been updated preventing the installation on Julia 0.7 or 1.0:

https://github.com/JuliaComputing/JuliaDB.jl/commit/8bf3057d...

A automatic check as in R would indeed a better choice.

Re: Julia 1.0

#268

Post by kazinator »

pjmlp wrote: post #130
ur-whale wrote: post #90

Earlier quoted context omitted.

It most certainly is for the vast number of folks who code in C, C++, Java, Python, etc ... It will for sure hurt adoption.

Some of those folks started when Fortran, Basic, Clipper, Pascal, Modula-2, Ada were relevant. 1 based indexes were just fine.

Vectors are zero based in Common Lisp; the 1960 Lisp 1 manual describes arrays; they are zero based.

Zero based is much more sane. If the array is regarded as being made up of larger groups of elements, say groups of 8, then ⌊index/8⌋ gives us the group and group x 8 gives us the base element of group. Not so if index is one-based.

Zero based multi-dimensional coordinates are easy to convert to a flat address. E.g. 3D case: just ABz + By + x.

Imagine distances were one based (so that either 1 m or 1 km means no displacement), and then trying to convert a given distance between m and km. Yikes!

Music intervals are one-based, to their great detriment. We end up with a "rule of nine" for interval inversion and that comes from the octave of the diatonic scale having seven notes!

One-based indexing is okay when the indices don't have a strong numeric meaning (beyond basic successor/predecessor relationships), or none at all (basically are symbolic and could be replaced by any set that can be enumerated by the natural numbers).

As soon as the index domain is involved in displacement calculations that feature multiplication and division, anything but zero based is disadvantaged.

Re: Julia 1.0

#269

Post by dnautics »

jabl wrote: post #236
dnautics wrote: post #199

Earlier quoted context omitted.

there's a reason why julia doesn't have a strong static type system. In julia, you can write a custom type, and immediately have access to all of the builtin libraries. For example, I wrote a drop-in replacement for floating points, and immediately had complex numbers, matrix math, gaussian elimination, fourier transform, etc... And could rapidly compare the numerical performance of that with fp. For a more exotic ex…

I don't see why what you've done couldn't in principle be done in a language with a static type system (except maybe with some difficulty the thing with verilog, which apparently needs access to the compiler at runtime?) To get good performance with a static type system, you need generics. Which means longer compile times, as the libraries you use must be compiled as part of your project so that the code specialized…

the primary use case for julia is where you expect to be doing computationally-intensive work over and over again (e.g. in a supercomputer deploy where I was using 20 HPC nodes over the course of 4 days), so the amortization of the (short) recompile time is worth it, and the ease of writing software using the julia generics is totally worth it. Also see the Celeste.jl project where they were able to very easily optimize for a super inconvenient platform (xeon phi).

If you're expecting a high-performance jit that needs to be called all the time because your program gets unloaded from memory and needs to be rebuilt by a kubernetes server every fifth web request, don't use julia.

Re: Julia 1.0

#270

Post by sampo »

jhayward wrote: post #252
Accipitriform wrote: post #211

Earlier quoted context omitted.

> Julia Computing is largely made up of people they've hired from the community straight out of grad school. Where do you think most companies get "professional programmers" from, exactly? Julia's been designed and implemented by some very bright people, and it shows.

Industry gets professional programmers by hiring people who have been hammering out shipping code in paying products for years, and years, doing support, maintenance, and new product development and research. Grad students may be brilliant but that does not help give them any insight in to what makes a good ecosystem, toolchain, and feature set good.

How was it with the origin and design with Python, NumPy, Matplotlib, Pandas? Were the people who originated these projects in their time any more professional and seasoned than Julia people are currently?
Post reply on HN