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

281–290 of 446 posts

Re: Julia 1.0

#281

Post by Certhas »

dangom wrote: post #214
ChrisRackauckas wrote: post #160

Earlier quoted context omitted.

This is what 0-based indexing looks like in data analysis: >In order to read a csv in that doesn't have a header and for only certain columns you need to pass params header=None and usecols=[3,6] for the 4th and 7th columns: https://stackoverflow.com/questions/29287224/pandas-read-in-... Just reading that hurts me.

This is very much a non-argument. Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th. Again, 0-based indexing exists to fit a purpose: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW... In my opinion, reading `a = b[1:n-1]` hurts much more than reading `a = b[:n]`.

It's not arbitrary. It's English. In the list [apple, orange, tree] which element is orange? It's the second element.

I have taught Python quite a bit, and I have gotten good at explaining 0 based indexing and slicing based on it. When I switched to Julia there was nothing to explain. And my code has about as many +/- 1s as before...

Re: Julia 1.0

#282

Post by vorpalhex »

rhymenoceros wrote: post #256
vorpalhex wrote: post #118

Earlier quoted context omitted.

Package management is a really-really-really difficult problem that is far from solved. Not to say that your critiques are invalid (quite the opposite), but Julia is just now hitting 1.0 - by contrast Node/NPM have been around quite a bit longer and still have terrible package issues they're working to solve. If you can, try and find a few hours to help pitch in and solve the package problems, even if it's just updat…

I know the JS ecosystem has some pretty counterproductive culture when it comes to package management (leftpad), but can you provide some examples of terrible issues still present in NPM? I hear this complaint often and I'm wondering what other people think of as insurmountable technical issues or design flaws in NPM.

I don't believe there are any insurmountable issues with NPM currently.

The current major issue, as it stands, is that it's very easily for a malicious bit of code to sneak into a heavily used JS package and have oversized effects - this happened very recently with a very popular linting-support package.

The other issue is general posting of malicious packages under mistyped names, or takeover of existing packages with malicious updates by new owners.

At the same time, nobody wants to have NPM (the org) manually vet every upload ever made. So, there's that.

Many JS packages are extremely dep heavy, overwhelmingly for minor features (checking something is an array, promise-fying FS, etc) which makes it very easy to infiltrate packages and very hard to vet a package entirely.

Finally, npm (the program) runs into a fair bit of caching woes and it's own dumb bugs which feel like they shouldn't slip into production nowadays. Oh, and sometimes npm (the website) goes down.

The answer for JS, unfortunately, is probably segmentation - as better managed and more secure package repos come up, likely with their own package managers, npm will probably have to up their game. That, I am sure, will bring a whole fresh set of issues.

Re: Julia 1.0

#283

Post by simonbyrne »

civility wrote: post #134
peatmoss wrote: post #62

Earlier quoted context omitted.

> 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success. I’m curious as to why this is a problem outside numerical computing. From my perspective, this is consistent with a long history of mathematics dealing with matrices that predates electronic computers. 0-based arrays are pop…

Zero based arrays are frequently better in a numerical context. Many times when you’re using the index in the computation itself (FFTs for instance), zero based is what you want. For instance, the zeroth frequency (DC) is in the zeroth bin.

Well for FFTs you really want periodic indices. Luckily Julia has those too: https://github.com/JuliaArrays/FFTViews.jl

Re: Julia 1.0

#284

Post by [deleted] »

vorpalhex wrote: post #118
29galoseats wrote: post #57

Earlier quoted context omitted.

I had a similar reaction about this being a little premature. On the other hand, I'm wondering if this will help a little with the dependency hell that's caused me to drift away from Julia over the last year or so. At first I was fairly excited about Julia, and greatly preferred it over R or Python for numerical work, library resources aside. It was fast and I liked the language design itself. Over the last year or t…

Package management is a really-really-really difficult problem that is far from solved. Not to say that your critiques are invalid (quite the opposite), but Julia is just now hitting 1.0 - by contrast Node/NPM have been around quite a bit longer and still have terrible package issues they're working to solve. If you can, try and find a few hours to help pitch in and solve the package problems, even if it's just updat…

[deleted]

Re: Julia 1.0

#286

Post by cultus »

typon wrote: post #240
cultus wrote: post #212

Earlier quoted context omitted.

Matlab is 1-based. That's what the vast majority of scientific programmmers still use. Worrying about 0 vs 1 is just useless bikeshedding, really. I've done lots of index heavy operations in Julia and in Python, and it's easy either way.

I think majority of scientific programmers use Python/C/Numpy stack over Matlab

No, not true at all. Engineering and academia are still solidly Matlab. You have to keep in mind that these people are not programmers, they are used to Matlab, and they don't want to learn another language. It's just a small proportion of new faculty and some grad students that use Python. Statistics is all R.

Re: Julia 1.0

#287

Post by pjmlp »

kazinator wrote: post #268
pjmlp wrote: post #130

Earlier quoted context omitted.

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

I also have read Dijkstra, it doesn't mean I agree with everything he wrote.

In Algol based languages indexes are customizable, I don't remember ever writing array [0..9] of Integer instead of array [1..10] of Integer.

C, C++ and their descendants took over and I just had to adapt.

Re: Julia 1.0

#288

Post by ChrisFoster »

marmaduke wrote: post #228
celrod wrote: post #200

Earlier quoted context omitted.

I think it is easier to write fast, complicated code in Julia than in C, C++, or Fortran. Not just the syntax, but because of great support for generic code by default and metaprogramming making it relatively simple to write code to generate the code you actually want for any given scenario. Interactive benchmarking and profiling are a boon too. An example of the value of generic code is that forward mode AD is extre…

What happens for that scientist when they have to dive into Julia’a stack to debug something weird? In Python and C, you have established debuggers, semantics etc, which means that, yes, there are two languages instead of one, but neither is a moving target compared to a language which just had a 1.0 release. I get the issue with scientists writing poor code, but Numba has largely solved this problem, by packing an L…

Sometimes low level debugging is a surprisingly pleasant experience as the julia JIT generates proper DWARF debug info. So for instance, you can break in gdb and see the julia source code for any julia generated stack frames, neatly intertwined with the frames of the C runtime.

To be clear, I don't remember needing to do this as a regular user. As an occasional compiler hacker it's been quite nice though.

Re: Julia 1.0

#289

Post by wuschel »

Does Julia have Tail Call Optimization for recursion?

I know it is not necessary, I was just curious, as thr language seems to have a lot of metaprogramming options, and Femto-Lisp being part of the compiler.

Re: Julia 1.0

#290

Post by int_19h »

ur-whale wrote: post #193
SolarNet wrote: post #184

Earlier quoted context omitted.

Ok, then use the built in Julia features to use any offset you want inside your algorithm's code. Compilers are pretty good about optimizing integer constants.

Everyone in this thread seems to believe that 1-based indices is a non-problem because Julia "offers a choice". My reaction: - the default is 1-based, which means the bulk of Julia code will adopt the convention and therefore the vast majority of coders in 2018 will have to do mental gymnastics to understand what the code does. - when I read Julia code, I will never know which convention the code was written with unl…

Languages that have offered that choice have been around for decades - Pascal, for example. It was never a problem in practice.
Post reply on HN