Live data from Hacker News

Giving up on Julia

zverovich.net

81–90 of 242 posts

Re: Giving up on Julia

#81
post #41
post #19

Earlier quoted context omitted.

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…

One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan. I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?

BLAS is an API, more or less.

https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra...

Re: Giving up on Julia

#82
post #58

Libraries? Sure. Ease of development, I cannot comment on. But measuring performance with timing a "hello world" program? Seriously? What scenario does the author have in mind that makes this particular benchmark even remotely relevant? The rest of the rant pretty much comes down to "it doesn't look like Python" (which is IMO a good thing, and I would certainly not call Python a "de facto standard of numerical comput…

does vectorization still result in a lot of performance loss compared to loops?

Yes, but it should be fixed in the nearish future. https://github.com/JuliaLang/julia/issues/16285

Re: Giving up on Julia

#83
post #19

Earlier quoted context omitted.

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…

If distances used 1 based indexing: metric distance conversion chart: cm m km 1 1.00 1.00000 2 1.01 1.00001 3 1.02 1.00002 ... 101 2.00 1.00100 ... 100000 1000.99 1.99999 The ratios between the values aren't fixed now; we can't go from cm to m just by scaling by 100. We must subtract, scale then add. One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.

Distance doesn't use indexing at all, because measures are not indexes, so it doesn't make sense to say "if distances used 1-based indexing".

OTOH, for something physical that actually is indexing, or at least closely analogous to it, we could ask "what if principal quantum numbers used 1-based indexing". But, then, the answer would be "things would look exactly like they do now, because it already does."

Re: Giving up on Julia

#84

Earlier quoted context omitted.

If distances used 1 based indexing: metric distance conversion chart: cm m km 1 1.00 1.00000 2 1.01 1.00001 3 1.02 1.00002 ... 101 2.00 1.00100 ... 100000 1000.99 1.99999 The ratios between the values aren't fixed now; we can't go from cm to m just by scaling by 100. We must subtract, scale then add. One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.

Distance doesn't use indexing at all, because measures are not indexes, so it doesn't make sense to say "if distances used 1-based indexing". OTOH, for something physical that actually is indexing, or at least closely analogous to it, we could ask "what if principal quantum numbers used 1-based indexing". But, then, the answer would be "things would look exactly like they do now, because it already does."

Distances can be quantized. If you're designing something in your CAD tool, you can set a grid to, say 1cm, and never place anything on a fraction of a cm. The coordinates of points in the design are then de facto addresses.

Indices can be regarded as measures. We speak about an array having a "size" or "length": that is measurement language. Something is "3 words wide": ditto.

A given record in a file can be 25 words from the beginning, or 100 bytes, or 800 bits. All of these tell us how much storage immediately precedes that record and we can easily convert among them.

If indices support calculation, they should be displacements, and displacements should originate at zero.

Indices not intended for calculation (beyond simple successor/predecessor, perhaps) can place items into correspondence with any ordered set: natural numbers, letters of the alphabet, and so on. This is where we can get away with 1 based.

Indices not intented for any calculation whatsoever can use a set: like associating character strings with objects via an "associative" array or whatever.

Re: Giving up on Julia

#85

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…

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…

R and Mathematica are also 1 based. And R really is popular (http://www.tiobe.com/tiobe_index?page=index - ok, popularity is droping right now, likely b/c of Julia ;-))

Re: Giving up on Julia

#86
post #78

Earlier quoted context omitted.

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

Are you aware of any language's whose FFI is that trivial?

Do I have to be aware of some other language with such a trivial FFI in order to question the claim that Nim has such a trivial FFI?

(C++ has such a trivial FFI, as well as non-GC languages which compile to C code... there may be more as well)

Re: Giving up on Julia

#87
post #19

Earlier quoted context omitted.

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…

If distances used 1 based indexing: metric distance conversion chart: cm m km 1 1.00 1.00000 2 1.01 1.00001 3 1.02 1.00002 ... 101 2.00 1.00100 ... 100000 1000.99 1.99999 The ratios between the values aren't fixed now; we can't go from cm to m just by scaling by 100. We must subtract, scale then add. One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.

Except that's counting, not indexing. It doesn't make sense to compare the two. It's more akin to the "is the first floor the ground floor or the one above it"-debate.

Re: Giving up on Julia

#88
As someone who does quite a lot of image and signal processing the fact that their arrays are 1-based is a complete deal breaker. The first few years of my career I worked with Matlab and I hated 1-based arrays with a passion. I think I never encountered a situation where the Matlab way makes stuff easier, almost always the 0-based index is the more natural choice.

After I switched to Python/C I can say that I never want to work with 1-index languages again.

Re: Giving up on Julia

#89

Earlier quoted context omitted.

If distances used 1 based indexing: metric distance conversion chart: cm m km 1 1.00 1.00000 2 1.01 1.00001 3 1.02 1.00002 ... 101 2.00 1.00100 ... 100000 1000.99 1.99999 The ratios between the values aren't fixed now; we can't go from cm to m just by scaling by 100. We must subtract, scale then add. One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.

Except that's counting, not indexing. It doesn't make sense to compare the two. It's more akin to the "is the first floor the ground floor or the one above it"-debate.

Perhaps you mean it's displacing not indexing?

Counting is indexing!

What is it that you do when you count items in a set? You put them into correspondence with the natural numbers, indicating each one as 1, 2, 3, ... The last integer is the count.

Yes, it is related to the "is the first floor ground, or the one above it"; and it's clear that some programming languages take their cue from stairs and elevators.

Nobody ever has to calculate "what is the floor twice as high as this one?" Moreover, people are unfazed by 13 missing.

(I haven't seen a language that omits 13 from indexing, fortunately.)

Re: Giving up on Julia

#90
post #72

I know R and have used Octave. I started learning Julia this morning after a physicist recommended it to me after he switched from python. I used Jupyter/Julia to simulate a neuron as a practice exercise. This is my experience as a beginner: 1. The static typing makes a big and positive difference. Its nice having a statically typed repl. 2. The documentation is good. 3. Using unicode symbols and \mu style tab comple…

> The base install is a bit bare.

I think the problem here is the library approach. They should break stuff out of Julia's core library and move them into default included libraries (like python does).

Post reply on HN