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

Julia adoption keeps climbing

hpcwire.com

Post reply on HN
Print view View original

261–270 of 309 posts

Re: Julia adoption keeps climbing

#261

Post by oivey »

legerdemain wrote: post #241
oivey wrote: post #223

Earlier quoted context omitted.

For the last thing, is this what you want? https://github.com/JuliaArrays/PaddedViews.jl There may be other packages or methods for doing the other things you want. I’d think that broadcasting over a NamedTuple would iterate over the key => value pairs, but I haven’t tried it.

Thanks for the good find!

Looks like vectorizing over NamedTuples is explicitly disallowed. Probably you can still vectorize things over the keys and values separately, along with some helper functions, but it is a bit annoying. Looks like the reason was due to questions on whether iteration should be over values or pairs.

Re: Julia adoption keeps climbing

#262

Post by leadingthenet »

oblio wrote: post #169
amelius wrote: post #76

My gripes, feel free to disagree: 1. Julia uses base-1 indexing. 2. Julia uses an "end" keyword everywhere, which is imho too verbose (and the corresponding "begin" is missing so it's inconsistent).

I can't say that I like or use Julia, but just regarding your comment, and because I've seen similar comments about other languages around: > 2. Julia uses an "end" keyword everywhere, which is imho too verbose (and the corresponding "begin" is missing so it's inconsistent). This is an absolutely childish approach to comparing or selecting programming languages. In my eyes, it says a lot about the maturity of softwar…

But a language's syntax is something you interface with literally every single time you're using it.

Why would (even simple) aesthetic choices in syntax not matter, if they're such a big part of the experience?

Re: Julia adoption keeps climbing

#263

Post by BadInformatics »

disgruntledphd2 wrote: post #252
BadInformatics wrote: post #193

Earlier quoted context omitted.

> is this really a problem that I'm going to come across in the real-world when 90% of our time is spent ingesting a poorly-formatted csv, doing some quick plots and perhaps building a model to test something out Yes, multiple dispatch is not some highfalutin ivory tower concept that only comes up in specialized code. For example, the model in question could define custom plotting recipes[1] so that you can just call…

> Yes, multiple dispatch is not some highfalutin ivory tower concept that only comes up in specialized code. For example, the model in question could define custom plotting recipes[1] so that you can just call plot() and have it produce something useful. This is literally the whole conception behind generic functions in R (print, plot, summary etc). I agree it's great, but Julia is building on a lot of prior art here…

For sure, and one would be remiss not to mention Dylan, CL/CLOS and Clojure here as well. My quibble was with the claim that multiple dispatch rarely shows up in practice, which you've pretty clearly shown is not the case in R!

Re: Julia adoption keeps climbing

#264

Post by ddragon »

leadingthenet wrote: post #262
oblio wrote: post #169

Earlier quoted context omitted.

I can't say that I like or use Julia, but just regarding your comment, and because I've seen similar comments about other languages around: > 2. Julia uses an "end" keyword everywhere, which is imho too verbose (and the corresponding "begin" is missing so it's inconsistent). This is an absolutely childish approach to comparing or selecting programming languages. In my eyes, it says a lot about the maturity of softwar…

But a language's syntax is something you interface with literally every single time you're using it. Why would (even simple) aesthetic choices in syntax not matter, if they're such a big part of the experience?

While you do interface with it all the time, it's not something you'll be thinking all the time, at some point it will be completely invisible even though it's there (unless you're that bored). What will really be a big part of the experience is what offers actual resistance to solving your problem and actively waste brain power and not muscle memory, be it the fact that language semantics forces you to write the same thing all the time when a particular feature (like macros) could handle it trivially, the lack of some particular type safety makes it so you keep losing time debugging the same error, the interactive tools being lacking forcing you to waste time debugging with prints, you have a workflow where the JIT lag keeps breaking your pace, the community doesn't have a culture of documentation making it so you'll lose time trying to decode the source, etc...

Re: Julia adoption keeps climbing

#265

Post by disgruntledphd2 »

BadInformatics wrote: post #263
disgruntledphd2 wrote: post #252

Earlier quoted context omitted.

> Yes, multiple dispatch is not some highfalutin ivory tower concept that only comes up in specialized code. For example, the model in question could define custom plotting recipes[1] so that you can just call plot() and have it produce something useful. This is literally the whole conception behind generic functions in R (print, plot, summary etc). I agree it's great, but Julia is building on a lot of prior art here…

For sure, and one would be remiss not to mention Dylan, CL/CLOS and Clojure here as well. My quibble was with the claim that multiple dispatch rarely shows up in practice, which you've pretty clearly shown is not the case in R!

Yup, the R-FAQ specifically calls out Dylan and CL as influences.

Re: Julia adoption keeps climbing

#266

Post by DNF2 »

arduanika wrote: post #255
laplacesdemon48 wrote: post #125

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

What a constructive, positive, down-to-earth, well-written comment, and what a nice reprieve from everything that's broken about the tone of web discussions these days. You point out that there's still another player in this space (R), but not in a way that's whiny, dismissive, or doctrinaire, and you celebrate the healthy competition. You suggest a streamlined path toward Julia ecosystem maturity, rooted in real-wor…

This whole thread seems to be quite civilized. I can see no name-calling or off-topic rants, only a frank exchange of opinions, mixed in with some facts.

Your post seem to indicate that there is some sort of 'fight' going on, or that the tone is broken. I disagree. If most web discussions were like this one, we would have fewer problems in this world.

Re: Julia adoption keeps climbing

#267

Post by cb321 »

galangalalgol wrote: post #116
mlthoughts2018 wrote: post #58

Earlier quoted context omitted.

Cython - in fact I think in 2021 if you want to write a pure C or pure C++ program, Cython is the best way to go, and just disable use of CPython. The “need to rewrite” is actually a sort of advantage with Cython. You only target small pieces of your program to be compiled to C or C++ for optimization, and the rest where runtime is already fast enough or otherwise doesn’t matter, you seamlessly write in plain Python.…

Does compiling with cython decrease the ffi overhead of the calls into native code? My problems with numpy have always been that I have to make a lot of calls on small bits of data and the ffi overhead eats all my performance gains. If I put more logic on the native side and made fewer bigger calls it would be faster, but that often doesn't make sense, or is a slope where putting the logic unto native pulls a data st…

Probably. Cython compiles a C-style superset of Python into C. Then a C compiler compiles that to a Python-importable DLL/.so. So, the overhead to call a C function is no more than declaring its types (programmer person overhead) and then, in the generated C, the native C-linkage function can be called like any other. Now, just one C function calling another from another translation unit (i.e. object file or shared lib) can be "high" overhead (nothing like Py FFI), but you may also be able to eliminate that with modern compilers with link-time-optimization with some build environment care.

Re: Julia adoption keeps climbing

#268

Post by snicker7 »

The most important aspect of any language are the trade-offs and values held by the designers and community. Julia takes a zero-compromise oath to approachability and performance. Julia is not (yet!) a perfect language, but those values make me want to invest in the ecosystem.

Re: Julia adoption keeps climbing

#269

Post by arduanika »

DNF2 wrote: post #266
arduanika wrote: post #255

Earlier quoted context omitted.

What a constructive, positive, down-to-earth, well-written comment, and what a nice reprieve from everything that's broken about the tone of web discussions these days. You point out that there's still another player in this space (R), but not in a way that's whiny, dismissive, or doctrinaire, and you celebrate the healthy competition. You suggest a streamlined path toward Julia ecosystem maturity, rooted in real-wor…

This whole thread seems to be quite civilized. I can see no name-calling or off-topic rants, only a frank exchange of opinions, mixed in with some facts. Your post seem to indicate that there is some sort of 'fight' going on, or that the tone is broken. I disagree. If most web discussions were like this one, we would have fewer problems in this world.

Oh, that's exactly what I mean -- when I say "everything that's broken about the tone of web discussions these days", I'm talking about threads and topics other than this one. I don't see any 'fight' here, and that's what's so refreshing.

Re: Julia adoption keeps climbing

#270

Post by mhd »

pjmlp wrote: post #152
mhd wrote: post #66

Earlier quoted context omitted.

What about "Ada", "Miranda" or "Haskell"? First names, too, albeit ones much less common these days. ("Linda" the language isn't even in that category, popularity-wise, although the source of the name seems to be a weirder story)

You forgot Pascal. :)

Alas, I also forgot poor Yorick.

(And combining both Wirth and Shakespeare, technically speaking Oberon is a valid first name, too)

There's also Chuck, Idris, Karel, Joy, Tom and arguably Euclid, Janus and Mercury.

The jury's out on "Rexx" and "Nial"…

Post reply on HN