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

231–240 of 446 posts

Re: Julia 1.0

#231

Post by marmaduke »

Accipitriform wrote: post #209
marmaduke wrote: post #186

Earlier quoted context omitted.

I see your comment grayed out, and I just want to chime in, as some who does a lot of numerical stuff (more than a decade, published stuff, support multiple lab research projects etc), I want to second this point of view. When it’s time to get real work done Python is more than good enough, and there’s plenty of strategies for acceleration where required. And when I want Julia’s promise of fast loops, I use Numba. If…

> And when I want Julia’s promise of fast loops, I use Numba. If all the effort gone into Julia had instead been spent on fixing remaining warts in Python workflow for science, we wouldn’t even havee this conversation. Python is rather a mess. Code written in Python can't be sped up without pain/cost, and apparently it will never support concurrency natively. It also suffers from the bane of weakly typed languages, e…

Python supports thread and process based concurrency. Most optimizations require effort, or they wouldn’t be called optimizations.

It’s not weakly types either: you can’t add a list to a string. It’s dynamically typed.

Re: Julia 1.0

#232

Post by tavert »

johnsea wrote: post #224
tavert wrote: post #202

Earlier quoted context omitted.

The reason I ran away from Julia and don't plan on ever using it again, and don't recommend anyone use it outside of academia, is that so much of the community is made up of grad students. So you get a lot of research code and people who have never been professional programmers maintaining most of the ecosystem. Julia Computing is largely made up of people they've hired from the community straight out of grad school.

I don't see your point of academia and about hiring from the community? What I see on Github is as professional as it can get. Issues, discussions, triage, review, CI-tests for example. Maybe you started too early, before Julia was settled? And/or were too over-enthusiastic to begin with? I think Julia had to grow, find the 'correct' solution with e.g. NA/Missing/Nullable. Break things b/c it didn't work out as expec…

Things are decent on average, but there's a persistent carelessness and rush to do things without paying attention to the consequences. More in packages than base nowadays, but there's a lot of merging and releasing things immediately without waiting for code review that could have caught mistakes before breaking users.

Re: Julia 1.0

#233

Post by mikec3010 »

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

Earlier quoted context omitted.

True, after they learn a programming language. I meant when we're children and taught to count, we don't start at 0.

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.

Re: Julia 1.0

#234

Post by coldtea »

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

>Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th.

No, that's their ordinal position, and how 8 billion non-programmers would refer them as in any everyday setting.

That's also how programmers would refer to them if it wasn't for a historical accident.

What's more, that's also how programmers refer to them when they talk between then and not to the machine ("check the 3rd column" not "check the column at the index of 2").

Re: Julia 1.0

#235

Post by johnsea »

marmaduke wrote: post #230
johnsea wrote: post #203

Earlier quoted context omitted.

> And when I want Julia’s promise of fast loops, I use Numba. This only works (easily) as long as you don't have user-defined types > If all the effort gone into Julia had instead been spent on fixing remaining warts in Python workflow for science, we wouldn’t even havee this conversation. Python is too dynamic, you cannot just fix remaining warts. From Julia documentation I know that Julia language has been designed…

Numba has user defined types, https://numba.pydata.org/numba-doc/dev/user/jitclass.html No one intends to fix Python but it’s straightforward to do things like Numba: use a decorator to read out the AST for a function, reimplement it however you like and pass back the compiled function, and document the semantics.

thank you

Re: Julia 1.0

#236

Post by jabl »

dnautics wrote: post #199
jabl wrote: post #192

Earlier quoted context omitted.

In principle Julia is a general purpose language, although so far the ecosystem is heavily biased towards scientific computing. So while you might find the language itself pleasant, you'll probably find a lack of libraries. (personally I'm a fan of strong static type systems (e.g. haskell), and I think it is a shame the designers didn't go down that path. But hey, they did all the work and not me, so who am I to comp…

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 for the types you're calling the library with is generated. You can't have piles of native code lying around just waiting to be used (like in the C world, for example).

But this is similar to how Julia does it at runtime, with the multi-methods being JIT-compiled for the types you're calling them with. So either way you pay the cost somehow (and yes, there are ways to reduce that overhead, of course).

Re: Julia 1.0

#237

Post by e12e »

jandrese wrote: post #108
peatmoss wrote: post #79

Earlier quoted context omitted.

Wow, I hadn’t seen this before. The history of this feud goes back before C. Thank you for a fascinating read!

Even Dijkstra weighed in on this: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

I've always found this a rather weak argument - he even implies that 2...12 is at least as clear (it being the starting point of the text).

I also thought I'd seen a longer text focusing more on the counting/indexing.

I still don't see the appeal of "element at zero offset" vs simply "first element".

I do agree that < vs <= etc can get messy. But outside of now fairly archaic programming languages I don't see the need. Just use a construct that handles ranges, like "for each element in collection/range/etc". (Or for math, "pattern matching" (or "for n in 1..m").

Re: Julia 1.0

#238

Post by ontouchstart »

StefanKarpinski wrote: post #190
semi-extrinsic wrote: post #137

Earlier quoted context omitted.

Contrarian view: having a division between "general scientists" and "programmer scientists" is a good thing. I really don't miss the bad old days of scientists doing write-only code from a cobbled-together mess based on Numerical Recipes, leaving behind spaghetti C99 or F77 for the next post-doc, commenting out routines for version control; giving us papers with numerical analysis that's not even reproducible by the…

I can understand how one can reasonably hypothesize that. In some sense you can see Julia as one big social experiment in what happens when you do everything possible to blur the line between users and developers of a scientific (and, of course, also general) programming language by solving the two language problem and making the language for users and developers one and the same. ... and it's been wildly successful.…

I was watching live stream last night from the East coast and very impressed by the achievement by you scientists and grad students since 2012. https://arxiv.org/abs/1209.5145

As a former physicist, I have been through the Numerical Recipes/F77 stage myself two decades ago. In the age of Big Data and Machine Learning, there are many ways to harvest the creativities in people who are not trained as professional engineers. Our software development mindset should be extended beyond the industrial "task oriented" products and platforms.

In the spirit of Turing machine and LISP where code is also data, we can even treat scientific computing ecosystems like Python/R/Julia etc. as models to capture creative scientific minds. It is AI at a high social level. The future is beyond our imagination.

We need more crazy meta programmers.

Re: Julia 1.0

#239

Post by e12e »

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

a = b[1..n]?

Re: Julia 1.0

#240

Post by typon »

cultus wrote: post #212
ur-whale wrote: post #195

Earlier quoted context omitted.

You just have to look at the most popular programming languages on 2018. They're all 0-based (with maybe R as an exception, but R is a niche language. If that's what Julia aims to remain -- their loss). The folks who designed these languages knew how not to alienate their future market.

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
Post reply on HN