Live data from Hacker News

Why Julia

ucidatascienceinitiative.github.io

61–70 of 257 posts

Re: Why Julia

#61

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…

You can change the indexing method if you want but that can introduce its own issues

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

Re: Why Julia

#62
I tried an earlier version of Julia (0.7). Then there was an update and all packages started breaking. There was no backwards compatibility. We had to rewrite a lot of code and completely change DB layer. I hope it's more stable now

Re: Why Julia

#63
post #7

Earlier quoted context omitted.

Multiple dispatch and meta programming are both wonderful, irrespective of speed benefits. For example, compare linear algebra syntax in Julia with those in R and Python. Plus, the flexibility of multiple dispatch applying equally well to any of your own types really makes it feel like you can do anything in Julia. Metaprogramming, writing code that writes code, can take a while to get used to. But is extremely power…

Multiple dispach and meta programming are available in python as well. Although duck typing is usually a better solution and it's not really a killer feature to data analysts anyway. Compared to python, i'd say julia has the reputation for being generally faster for things you can't use numpy with, and you can more easily scale multiple cpu or machines.

By metaprogramming in Python, do you mean using decorators ? If so that's a far cry from metaprogramming

Re: Why Julia

#64

Earlier quoted context omitted.

> It's like using `from package import ` and then complaining Python doesn't namespace properly. It really is not: * `from package import ` is more work than `import package`, `using` is shorter than `import` * the official documentation Python documentation starts with qualified imports, then introduces local bindings, and finally unqualified imports, opening a few doc pages imports are either fully qualified or exp…

> `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 and 4. significantly more comfortable to type.

If Julia's community doesn't want people to use it everywhere, they're doing a very, very good job of fucking with and victimising their users by way over-incentivising the use of `using` over `import`.

> And in the right direction: for trying things out interactively, `using ThePackage` and then having everything available is great.

And for writing maintainable code it's terrible, despite being by far the easiest and most convenient solution.

ChrisRackauckas complains that people use `using` over `import`, literally everything in the language and documentation pushes them towards it.

Putting the convenience of interactive sessions way, way over that of proper programs does not seem like "the right direction" to me, especially not when people then jump on their high horses and chide users for doing what the language unambiguously pushes them towards.

> But serving both of these needs seems like a valid design goal.

Python does that just fine: it provides convenience for interactive use without pushing users towards the least maintainable and desirable option.

Re: Why Julia

#65
post #31

Earlier quoted context omitted.

Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programming language) - with the benefit of speed - and no/hardly any need to drop to/link to C libraries - "everything" is in Julia, and you can inspect the code "all the way down" (well, to a point - there's of course llvm at the bottom). Whether Julia is that for you…

> and python (a sane, real programming language) So... R is an unreal language then?

[deleted]

Re: Why Julia

#66
post #62

I tried an earlier version of Julia (0.7). Then there was an update and all packages started breaking. There was no backwards compatibility. We had to rewrite a lot of code and completely change DB layer. I hope it's more stable now

There was a big transition to 1.0 last year, for which 0.7 was a transitional release (1.0 but with deprecation warnings for old syntax). The package ecosystem took a few months to catch up, which may have been a confusing time to start.

The promise now is that things should be more stable.

Re: Why Julia

#67

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…

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.

Re: Why Julia

#68

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.

> I think it requires a jvm mindset, warmup once and iterate inside rather than outside. I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful! For example, imagine I have a collection of a few hundred images with their projection matrices (in text files). I want to crop them and apply a simple imagemagick operation (which is not available from inside julia). The elementary…

>I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful!

Yet you picked a specialized tool "imagemagick" (made for working with images), and want to drive it by another specialized tool (the shell, made for file and process management).

Since you want "mindset oblivious" tools why not write everything from scratch, in C?

Re: Why Julia

#69

I did a 5000 line dissertation project in Octave after rejecting Julia. Reason : I had derived the math in linear algebra including Kronecker products; the math mapped to Octave pretty directly, but Julia requred me to translate all the Kronecker products to loops —yuck! kron(A, B) would become 12 lines of weird indices and for loops. On the listserv I was told that Julia was great because it didn't require vectoriza…

As notation for array based algorithms, Octave/Matlab is vastly better than anything else I've found. Some guy did PRML in Matlab, others have done it in Python. The Matlab version is like reading a book; clear, concise, correct. https://github.com/locklin/PRMLT IMO for most people, for array based algos, Matlab hits the "notation as thought" Iverson saying in a way that APL didn't quite make it.

For such things, Julia is often very close to Matlab indeed, or at least it can be used that way.

You could translate most of those files line-for-line, with quite a few lines identical or trivially changed (bracket shape, or max -> maximum). This is often a useful thing to do, get a transliterated version running, and then re-write bits of it more idiomatically, while checking that the output is identical.

Re: Why Julia

#70

Earlier quoted context omitted.

I actually like 1-based for numerical work. A lot of great languages (Smalltalk, APL, Lua...etc) use it too. It makes sense with matrices.

This is something I don't fundamentally understand. As someone who works a lot with MATLAB I'm very used to and like 1-based indexing. But when I use C or Python, 0-based indexing is not something I complain about or hold against the language. It's just the way things are. Maybe if you don't think of it in terms of a different index basis and instead you think of it as indexing vs. offsets then it becomes easier to s…

If that's someone's biggest complaint against the language, then I'd say the language must be pretty awesome ;-)

It's basically bikeshedding. "But I look at the shed all day..." "But I'm used to looking at reddish colors..." "Red is more correct than green because ..." Let's all move on to more important things :-)

Post reply on HN