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

Giving up on Julia

zverovich.net

Post reply on HN
Print view View original

211–220 of 242 posts

Re: Giving up on Julia

#211

Post by e12e »

rixed wrote: post #183
e12e wrote: post #178

Earlier quoted context omitted.

That argument never felt very convincing to me. Perhaps because it really is about aesthetics, not some deep philosophical ideas connected to numbers. I see it as rather simple. If you're listing off-sets, starting at 0 makes sense, because there'll be something there. But if you're counting elements starting at 1 makes more sense. I don't have 9 fingers offset from my first one, which I call finger zero; I have ten…

Indexing is not for counting elements, it's to reach a particular one.

I still find it more useful to name it my tenth finger, rather than the ninth from the first. And I'm fine with my middle finger, finger number three - being the one that sits between the pairs of fingers made up of finger number one and two, and fingers four and five. I don't really see how it's any better to count up from the zeroeth offset of the first finger to the second offset to get to the middle finger.

Re: Giving up on Julia

#212

Post by pathsjs »

jjnoakes wrote: post #70
pathsjs wrote: post #68

Earlier quoted context omitted.

Nim compiles to c, hence you can just call c functions. All you need is a signature, which can even be generated automatically from a c header. You can manually allocate memory if you want, and you can also pass pointers, either to manually allocated or gc memory. The gc will not run when c is working, since it is triggered by allocation

So if I call from Nim to C (passing a gc'd Nim-owned pointer), then that C routine calls back into Nim (via a function pointer, or some other way through the FFI), the nested Nim routine may trigger gc and wipe out the pointer my C code is working with?

The situation that you describe could happen, but it is quite rare in practice. Usually, I call c functions that do their work and be done, such as BLAS.

For such cases, you can either manually allocate the pointers you pass to c, or temporarily disable the gc. Each thread has its own heap, so gc for one thread does not break anything in other threads

Re: Giving up on Julia

#213

Post by johnsea »

ScottPJones wrote: post #208
davidacoder wrote: post #171

Earlier quoted context omitted.

I've been using julia for a little more than two years now. I've been subscribed to all the mailing lists and regularly read the github issues. Not all of them, but a fair share. I've never, ever seen any behavior by any of the core devs that one could even remotely describe as toxic, rude or anything like that. The community is actually really helpful and supportive. I have seen this point about a toxic dev been mad…

The rude behavior definitely exists, I can point out a number of examples if you send me your e-mail address (you can look me up, @ScottPJones on GitHub, easily enough). I've seen that that sort of disrespectful behavior tends to spread in the community, unfortunately, when nobody dares call out one person for their comments and actions, because of their position.

But then - as a bystander - let me mention that I once wondered about your insistent replies in some gh issue. God, can't he stop, I thought, and, wow, they have patience. Fortunately such a situation is rare and I'm very often impressed by the intelligent friendly conversations I see. A lot to learn.

Re: Giving up on Julia

#214

Post by tavert »

Fede_V wrote: post #199

Julia aside, Keno, kudos for being an absolute class act and replying to everything so politely. For what it's worth, my impression of Julia has been overwhelmingly positive, and all the developers I've interacted with have been polite and friendly. I haven't made the switch from Python because: - I prefer the Python syntax - I like Python libraries (I know about PyCall, and it rocks) - The increased speed of Julia d…

> this requires timholy's fast lambda package

Not on nightly. That's fixed now. The technical concerns here about startup time etc are fixable, we'll get to them.

Re: Giving up on Julia

#215

Post by xxs »

mindcrime wrote: post #140
bluecalm wrote: post #75

Earlier quoted context omitted.

The thing about 1 based indexing is that it's a kind of in your face "this is different" decision from the point of view of a programmers of most popular languages. To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. It's not that I think they are incompetent but it's clear they care way more about some different world than ab…

To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. Possibly because you're used to working with languages like C, C++, Java, Pascal, Javascript, Python, etc. But in the world of languages tied closely to scientific / mathematical programming (Matlab/Octave, R, etc.) 1-based indexing is the norm. If you'd "grown up" so to spea…

Around 3 decades ago when started with BASIC, Pascal/Delphi 1-based index was pretty much the norm and off-by-1 mistakes were significantly more dominant.

Switching to zero based index Java/Javascript/C felt a lot more natural (no need for upper bound, always include->exclusive when it comes to bounds). Many algorithms benefit greatly from as well (hashtables + bitwise AND, for instance)

Virtually I do not recall making off-by-one errors while working with Java. Whilst it could be attributed to personal experience, the loops construct "for (int i=0; i0;)" appear quite intuitive. Strict bounds (i.e. ) feel more elegant as well.

Seeing, using both type of indexing, 0-based one would a winner by large margin in my book.

Re: Giving up on Julia

#216

Post by pathsjs »

jjnoakes wrote: post #74
dom96 wrote: post #73

Earlier quoted context omitted.

You can instruct the Nim GC to not do that using GC_ref ( http://nim-lang.org/docs/system.html#GC_ref,string ).

That's what I figured. So not "trivial".

You are right, this situation is not trivial. But it is also quite rare in practice

Re: Giving up on Julia

#217

Post by waldir »

ihnorton wrote: post #13
KenoFischer wrote: post #9

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

> For packages that needs arrays of indices, it would be quite easy to define an `IndexArray` type that does the translation automatically. (just to add: there is currently an open pull request from a core array-focused developer adding such support to base)

I believe this is the PR in question: https://github.com/JuliaLang/julia/pull/16260

Re: Giving up on Julia

#218

Post by nerdponx »

vitaut wrote: post #170
bmh100 wrote: post #127

Earlier quoted context omitted.

Sorry if I was being vague, but what situation would you re-run a short computation by executing the whole program again instead of using subroutines? Are we talking about a data scientist performing initial, exploratory analysis on a very small subset of data?

> Are we talking about a data scientist performing initial, exploratory analysis on a very small subset of data? Yes, that's one example. Also when debugging one usually uses small data sets. There are plenty of cases where runtime is short. I think the problem is that Julia is somewhat vague on how it should be used. If it stated explicitly that it is intended to be used in MATLAB-like fashion with one long-running…

In that case, it should seem like a fix is as easy as keeping an IJulia kernel running in the background all day.

Re: Giving up on Julia

#219

Post by yoplait_ »

azdle wrote: post #49
unlinker wrote: post #34

Earlier quoted context omitted.

Why is strong/dynamic typing considered such a big deal?

The way that I see it is that it's a factor that is very much in the front and center of how a developer usually uses the language and their preference tends to fall out of the mentality in how they're writing their code. A static-strongly typed language will pretty much always take more time to write, you have to be a bit more methodical in what you're writing because sometimes changing one thing means changing type…

> that can mean that large projects can end up being less maintainable in the future because you don't usually have a type checker

That's not true if you seriously unit-test your code base, which you should in both cases.

Re: Giving up on Julia

#220

Post by jjnoakes »

pathsjs wrote: post #212
jjnoakes wrote: post #70

Earlier quoted context omitted.

So if I call from Nim to C (passing a gc'd Nim-owned pointer), then that C routine calls back into Nim (via a function pointer, or some other way through the FFI), the nested Nim routine may trigger gc and wipe out the pointer my C code is working with?

The situation that you describe could happen, but it is quite rare in practice. Usually, I call c functions that do their work and be done, such as BLAS. For such cases, you can either manually allocate the pointers you pass to c, or temporarily disable the gc. Each thread has its own heap, so gc for one thread does not break anything in other threads

It's just those "quite rare in practice" bugs that I'm concerned about. Those tend to cost the most.
Post reply on HN