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

Why Julia

ucidatascienceinitiative.github.io

Post reply on HN
Print view View original

171–180 of 257 posts

Re: Why Julia

#171

Post by zimablue »

saosebastiao wrote: post #162
zimablue wrote: post #153

Earlier quoted context omitted.

I guess, because often you're not arguing in order to convince your opponent, you're arguing to sway the crowd (and sometimes, decide yourself). And I don't think they're idiots, I just think that they're wrong. Not many people have read Djikstra and (?) and have deep faith in mathematical beauty, or have even thought about this much, doesn't make them idiots.

The most prominent programming languages designed specifically for mathematical purposes (Mathematica, MatLab, Julia, R, Fortran), all have 1-based indexing. That should be a sign to you that 1-based indexing has a legitimate mathematical rationale. Djikstra wasn't speaking on behalf of the mathematics community. The idea that if you have deep faith in mathematical beauty that you'll come to the same conclusion is ab…

I'm pretty sure that they just copied Fortan, which was written most of a century ago.

That's the second time you've ridiculously misrepresented my statements: "anyone disagreeing with you is an idiot" "deep faith will lead you to the conclusion" (and not deep faith + thinking about the actual problem, several convincing arguments and some ability)

Re: Why Julia

#172

Post by darkpuma »

masklinn wrote: post #64
improbable22 wrote: post #59

Earlier quoted context omitted.

> `using` is shorter than `import` By one letter! And in the right direction: for trying things out interactively, `using ThePackage` and then having everything available is great. Then once you know what you want to do, in more careful code you can switch to `import` and qualify more things, and your future self with thank you. But serving both of these needs seems like a valid design goal. I'm not sure the manual d…

> By one letter! Yes, by one letter. Out of 6. "using" is 16% shorter than "import". And it uses better keyboard alternation (the first 4 letters of `import` are on the right side of a qwerty keyboard, the last 2 on the other, for using the only "i" and "n" are consecutive letters on the same half of the keyboard). So "using" is 1. introduced first 2. the primarily documented import mechanism 3. significantly shorter…

>Yes, by one letter. Out of 6. "using" is 16% shorter than "import". And it uses better keyboard alternation (the first 4 letters of `import` are on the right side of a qwerty keyboard, the last 2 on the other, for using the only "i" and "n" are consecutive letters on the same half of the keyboard).

Counterpoint: I am going to attempt an autocomplete after two characters by pressing tab. Typing 'us' leaves my left hand, the tab hand, as the last used hand before the tab. This prevents me from buffering the tab by moving my hand into position while typing the first two characters. 'im' is typed very easily with my right hand and while I'm typing that, my left hand is free to move into position over the tab key.

Re: Why Julia

#173

Post by [deleted] »

sgillen wrote: post #170
siproprio wrote: post #165

Whenever I see people claiming that Julia is fast, I feel like they are cheating. It is only fast if you don't count the "compilation" times. For example, every time you are trying to plot something ```using Plots```, it will take over 40 seconds to compile the Plots package. Then, you have the large memory usage. In my experience, plotting in Julia requires approximately 14x more RAM than in python or Matlab. Julia…

That's the trade off I guess, because of the JIT you have a slow initialization followed by very fast code. That's not really good for a lot of workflows though (if you're running a smallish script over and over for example).

[deleted]

Re: Why Julia

#174

Post by oxinabox »

ummonk wrote: post #41
ritoune wrote: post #21

The main issue I encountered as a Julia user is that multiple dispatch doesn't scale very well. When you start building out a project, it's easy to keep track and debug if multiple dispatch starts failing (i.e. type starts spreading everywhere and Julia slows to Python like speeds). In medium-to-large projects, it becomes extremely cumbersome to manage this. It's doable, but adds a layer of complexity management to p…

Yeah, my biggest want for Julia 2.0 would be a built-in static type analyzer.

That is neither a breaking change, (and thus could come in 1.3) Nor something that needs to be baked in. (thus could be in a package)

Re: Why Julia

#175

Post by throwawaymath »

zimablue wrote: post #142
ModernMech wrote: post #139

Earlier quoted context omitted.

I'm not convinced. I've written a great deal of software in C++ and MATLAB. I don't see what the big deal is either way. You say this thing has been "decided 20 years ago" (by whom?) but that's clearly not the case, as myriad languages that use 1-based indexing are in existence, continue to come into existence, and are used to great effect. You cite Djikstra's argument (well, you didn't actually cite it [1]) but his…

Much like turing completeness, you can build systems with any choice that "work", so an argument always has to be from aesthetics, which can include simplicity and "uglyness", but these aren't totally individual (you can get 99/100 people to agree on which of two schemes is "simpler"). Simplicity and beauty aren't something that even mathematicians dismiss as they can be trying to tell you something. There's another…

> an argument always has to be from aesthetics, which can include simplicity and "uglyness", but these aren't totally individual (you can get 99/100 people to agree on which of two schemes is "simpler").

Putting aside the implicit claim that something as subjective as aesthetics will be agreeable by 99% of the population...is 0-based indexing simpler? Why?

Your next example is...a little all over the place mathematically, if I’m being honest. I’m having trouble following it. But let me try...

So you’re saying I have a 1-dimensional, ordered set S, whose elements are real numbers. It can’t be an interval, because S needs to be discrete for this to be possible computationally or even theoretically (S is uncountable if its continuous, and thus cannot be indexed). It needs to have an order to have a sense of position in the first place, so map S to the natural numbers in whatever way you choose.

Now choose an element s in S. You want me to pick the first n elements from s that are “next”, for whatever your order relation is. We’ll call that relation s be an element of S, and choose an n-tuple N of elements

    (x_1, x_2, x_3, x_4, x_5, x_6) in *S*
such that s k of S such that k in S, s k k not in N.

Haven’t I accomplished your exercise just fine without using 0 indexing? If I were programming this, I could index the n-tuple starting with x_0 or x_1. I don’t understand the issue - what are you trying to convey here? Personally, I’d program this by defining S to be my vector or list or whatever, k to be the index of s in S, then defining my n-tuple with:

    N = []
    for (i = 1, i
I feel as though you only believe your example is compelling because you’re overlapping the origin with the initial index. But when you abstract your problem to the general case (as I did), then it doesn’t really seem to matter much. Your example is actually kind of a narrow edge case.

Re: Why Julia

#176

Post by munro »

RivieraKid wrote: post #98
dnautics wrote: post #67

Earlier quoted context omitted.

Sorry, why do you need OOP? I haven't coded OO in about 10 years now. (Mostly Julia, elixir, and functional JavaScript). It's great. Would never go back.

Because sometimes it's better for readability and conceptual simplicity to structure the code as objects connected to each other. Most of large-scale successful projects, often written by better developers than me or you, use OOP.

> Most of large-scale successful projects, often written by better developers than me or you, use OOP.

Ad hominem if I ever saw one.

Re: Why Julia

#177

Post by babahoyo »

sgillen wrote: post #170
siproprio wrote: post #165

Whenever I see people claiming that Julia is fast, I feel like they are cheating. It is only fast if you don't count the "compilation" times. For example, every time you are trying to plot something ```using Plots```, it will take over 40 seconds to compile the Plots package. Then, you have the large memory usage. In my experience, plotting in Julia requires approximately 14x more RAM than in python or Matlab. Julia…

That's the trade off I guess, because of the JIT you have a slow initialization followed by very fast code. That's not really good for a lot of workflows though (if you're running a smallish script over and over for example).

If you are running a script over and over (or using small modules to do organize things) it will be very fast and easy to work with. The compilation is just for the first time a script is run, not every time.

It really isn't a barrier any more than, say, waiting for `library` commands in R.

Re: Why Julia

#178

Post by ssivark »

zimablue wrote: post #147
saosebastiao wrote: post #145

Earlier quoted context omitted.

It sounds like you haven't considered any of the multiple reasons or situations where 1-based indexing works out better.

If you're going to give a counterexample, please give it. I thought about my post after I read it and came to this- given Djikstra's (only system which can describe an empty interval and interval with first element without "unnaturals" ) and (?)'s argument that it creates a nice homomorphism between real-number intervals and integer slices then it's inarguable to me that 0-based is more mathematically elegant. Where…

Since @zimablue seems serious about this, and for those who care as much about the array indexing question and why Julia's "arbitrary" indexing might be useful, here are links to a couple of my previous comments [1,2] on HN:

[1]: https://news.ycombinator.com/item?id=15473169

[2]: https://news.ycombinator.com/item?id=15472933

--

The idea is that the interface to the data structure should ideally closely match the semantic meaning of the data (timestamps, frequencies, etc.) rather than memory addresses/pointers. That lets you program at a higher level of abstraction. More generally, both zero-based and one-based indexing have their natural uses, depending on what you're referring to. Eg: consider floors in a building. If you wish to index the horizontal surfaces separating the spaces, it's more natural to start with zero for the "ground level". If you wish to number the spaces between the surfaces, then it's more natural to start with one for the "first floor". Which one is more convenient depends on the semantics of the problem domain and what ideas you wish to communicate. Being overly attached to one perspective is unhelpful.

To quote myself from those links:

> The way I think of it is that different indexing schemes suit different problems. I want to think carefully about the problem domain and use the most convenient convention. For example, when my array stores a time series, I would like the index to correspond to timestamps (and still be performant, so long as my timestamps can be efficiently mapped to memory locations, which is true for affine transformations, for example). When another array stores the Fourier transform of that time series, I would like to access elements by the frequency they correspond to. That stops me from making annoying indexing errors (eg: off-by-1), because the data structure's interface maps nicely to the problem domain. I find that much easier than the cognitive cost that comes with trying to shoehorn a single convention on every situation. But it's difficult to appreciate that when thinking of language constructs divorced from specific problem domains, as one tends to do when typically studying data structures and/or algorithms.

> [Regarding offset array indexing...] Think of this feature as blurring the distinction between data (accessing an array) and computation (calling a function). The fact is that arrays as they are used (contiguous memory location collection) often carry more information than being just a dumb list of arbitrary data, and it's very convenient to expose that in their interface.

Now, for example, an array can more closely resemble a cached function computation, because the interface to both carry the same semantic meaning.

Re: Why Julia

#179

Post by kbp »

spaced-out wrote: post #161
StefanKarpinski wrote: post #154

Earlier quoted context omitted.

Python also doesn’t have interfaces or access modifiers. Would you consider Python to have bad support for OOP by those criteria?

Yes, Python definitely has bad support for OOP.

Smalltalk doesn't have them, either.

Re: Why Julia

#180

Post by throwawaymath »

agumonkey wrote: post #14
enriquto wrote: post #6

> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).

I didn't find it slow, but: $ time julia -e 'print(1)' 1 real 0m0.438s user 0m0.300s sys 0m0.118s $ time python -c 'print(1)' 1 real 0m0.040s user 0m0.036s sys 0m0.003s it is slower.. That said, instanciating julia every step of a bash loop.. I think it requires a jvm mindset, warmup once and iterate inside rather than outside.

To demonstrate how slow the startup time is, here’s the respective times for executing ‘print(1)’ from Bash and from REPL on my machine:

REPL:

    julia> @time print(1)
    1  0.000031 seconds (7 allocations: 272 bytes)
Bash:

    $ time ./julia -e 'print(1)'
    1
    real    0m0.184s
    user    0m0.156s
    sys     0m0.168s
So yes, that’s a slow launch time. If you use Julia in a shell script and it’s starting up Julia on each calculation it will be brutally slow. Five orders of magnitude slower, in this case.
Post reply on HN