Live data from Hacker News

Why Julia

ucidatascienceinitiative.github.io

181–190 of 257 posts

Re: Why Julia

#181

Earlier quoted context omitted.

It doesn't have interfaces for example. It doesn't have access modifiers. Also, not sure if this belongs to OOP but working with optionals is cumbersome.

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

Smalltalk might be a better example.

Re: Why Julia

#182

I want to like Julia but after a decade of Python, every time I try it, it’s a death by a thousand cuts (and outdated Google results). I just can’t afford to have productivity drop to near zero for the learning curve plus reimplement everything. Also I ha e found multiple dispatch to be harder than regular OO methods to locate (for IDEs but grep also).

Have you tried methods(some_function) or the @which macro?

Yes - doing @edit(arg1,arg2,....) opens the file at the relevent method definition (ie version the same type arguments as given) in my editor. In the julia source code or my own modules.

Re: Why Julia

#183
post #112

Earlier quoted context omitted.

All fair enough but not particularly relevant here (in the context of "why Swift"). For doing numeric work in a language actually defined for that purpose, you will have proper 2D (and hopefully n-D) arrays, and hopefully slicing operations on them. So you'll never do this. In this context doing 2D indexing in 1D arrays is a code smell. It does come up in the case of writing libraries for general purpose language wit…

Well, the nice thing about doing 2d indexing in 1d arrays is the 1d array sits in one contiguous block of memory, which can be important for performance, and also makes it a lot easier to pass the array to C libraries (which I think you alluded to). Whereas in a lot of languages, int[3][3] might be stored as 3 pointers to 3 arrays. I imagine Julia optimizes this?

Many of the low level libraries for numerical computation are coded in Fortran, which is 1-based. So it is a wash in this aspect.

Re: Why Julia

#184

I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…

out of interest what would you consider medium sized?

Re: Why Julia

#185

Earlier quoted context omitted.

Agreed, that's my experience as well. Julia is amazing for scripts and smaller projects, but I wish there was something like Swift (which I'm increasingly convinced is closest to the ultimate general-purpose language) with all the nice things that Julia has. Specifically, these things make Julia less suitable for larger projects: - Lack of support for OOP. And no, purely functional programming is not the best way to…

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.

I would be more interested in why needing dynamic typing is such a deal breaker

Re: Why Julia

#186

I wish Julia would be more strict wrt type coercion of integer to float values. I've once spent a day debugging the issue caused by the following line of code, where t1, t2 are floats and v is an array: d = (t2 - t1) * length(v) It should've been LinearAlgebra.norm():Float instead of length():Int. Had julia been stricter the code would have failed to run, saving me much time.

I actually can't think of a single language that doesn't allow you to multiply an integer and a floating point value, yielding a floating point result.

Ada?

Re: Why Julia

#187

Earlier quoted context omitted.

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)

One based indexing is used in tons of domains within mathematics.

Fortran chose 1-based indexing for a very obvious reason...it was the best translation from the mathematics literature that they were trying to implement. Because matrix notation uses 1-based indexing! MatLab, a language designed specifically as a high level language for matrix mathematics, chose it for the same reason. R, a language for statistics, chose 1-based indexing because it is a statistical language, and counting is one of the most fundamental operations in statistics, and 1-based indexing is the form used for counting.

Mathematicians obviously have no problem switching back and forth between 0-based and 1-based indexing for different domains, so it boggles my mind that computer scientists have turned it into such a huge holy war, and even more mind-boggling that 0-based zealots claim to have mathematics on their side.

Re: Why Julia

#188

Earlier quoted context omitted.

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 mathematic…

Hey, thanks for trying to reply substantively. You haven't understood what I was saying, which is fair enough because I didn't present it very clearly probably. The line where you start talking about something else is this: "So you’re saying I have a 1-dimensional, ordered set S, whose elements are real numbers". No, I'm not saying that. Firstly to define the question as Djikstra does: we're arging about, if I have a list L, and I write into my computer L[a, b], which elements of L are returned? My argument is kind of a physical metaphor, take the real number line as a physical axis (like you're doing physics), and take a load of toy trucks that each have length of 1 (I guess you choose your coordinate system to make the length 1) and put them down end to end. If I was a physicist, and I asked you to pick up 3 trucks starting at 0, and I was using real numbers and a vector I'd say it like this, pick up the trucks in the range [0, 3) on my axis.

Now if you choose 0 indexing + (closed, open) for your slicing, then a (python) programmer would say to another programmer, take the slice [0:3] to get the 3 trucks. So the slice numbers correspond perfectly to the vector description of the space that the items occupy. That's why in this slicing system taking L[a, b] then b-a = the number of items you get. Because it's matched perfectly with a real-number vector description of the space the items occupy on a real number line. All the other advantages like (I can describe an empty interval: [0:0]), I can describe taking the last element and it feels right [-1: 0] follow from this physical-space homomorphism. That last one: in a circular (modular?) space, walk left 1 and then come back right 1 and pick up the element you pass over. In 1-based: [0: 1] = the last element? I don't know if any languages do this but either you can't and that's sad or you can and it is incredibly counterintuitive.

Re: Why Julia

#189

I didn't know about the Unicode tab completion. I gave it a whirl on the cli and loved it. Then I tried it out in julia-mode in Emacs, and it works there too! What other editors support this?

vim: https://github.com/JuliaEditorSupport/julia-vim I have an F-key shortcut in my .vimrc to turn this on mainly for non-Julia files, so that I can type (maths-y) unicode in Markdown / text files.

Re: Why Julia

#190

Earlier quoted context omitted.

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 bru…

honestly, parent had a use case in mind but it's ultra orthogonal with julia's goals. They're aiming at large numerical problems.. as I said above, if you need julia to make a quick one shot computation in a bash script loop, by all means use something else. But my bet is that anybody reading about julia is planning to do the heavy work inside of it, in which init time will probably be insignificant.

It's a bit annoying it's true, a well featured language with dynamic/repl appeal that is not in the ms launch time. But alas..

Post reply on HN