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

51–60 of 257 posts

Re: Why Julia

#51

Post by ChrisRackauckas »

masklinn wrote: post #48
ChrisRackauckas wrote: post #25

Earlier quoted context omitted.

A lot of this blog post is addressed by just using `import` instead of `using`... so it was actually just an issue of not reading the manual. It's like using `from package import *` and then complaining Python doesn't namespace properly.

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

Right, so this is a documentation thing, and I agree the docs should probably be changed a bit. But it's not a language thing.

Re: Why Julia

#52

Post by scottlocklin »

forkandwait wrote: post #33

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.

Re: Why Julia

#53

Post by ModernMech »

4thaccount wrote: post #35
Datenstrom wrote: post #8

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…

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 switch between the two?

Re: Why Julia

#54

Post by FabHK »

kgwgk wrote: post #46
ChrisRackauckas wrote: post #44

Earlier quoted context omitted.

That's just integer overflow.

I know. But I don't think that's the correct (floating point) result most people would expect, so it's worth signaling. julia> 2^62 4611686018427387904 julia> 2^63 -9223372036854775808 julia> 2^64 0

To be fair, though, this behaviour (namely, staying close to machine arithmetic) has been discussed and decided upon, and advertised. It's what enables the speed.

C/C++ makes the same choices, by and large.

Re: Why Julia

#55

Post by RivieraKid »

Datenstrom wrote: post #8

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 code all projects.

- Dynamic typing.

- Doesn't compile to native code (there are ways to do it, but too complicated and there are caveats).

- Module system doesn't seem to be design well.

- You can't use a function before it's defined.

Re: Why Julia

#56

Post by Datenstrom »

ChrisRackauckas wrote: post #25
Datenstrom wrote: post #23

Earlier quoted context omitted.

I do not recall the exact issue anymore unfortunately, I abandoned the project because of it, but the general sentiment on the Julia discourse seemed to be just avoid them. This blog post seems to sum up my issues with modules and namespaces pretty well though: http://luthaf.fr/julia-some-criticism.html I think that these issues are generally acknowledged although I don't know if they will be addressed. Seems like ma…

A lot of this blog post is addressed by just using `import` instead of `using`... so it was actually just an issue of not reading the manual. It's like using `from package import *` and then complaining Python doesn't namespace properly.

Although I read the module documentation I did indeed miss that, I was learning mostly from the Julia tutorial notebooks and am definitely a Julia noob. Julia's `using`, `import`, and `include` does seem like it could have a better design. In Rust or Python for example anyone could tell the difference without looking at the docs. I assume `using` was kept for backwards compatibility?

I'll need to take another look at the code I was working on. I was planning on doing so after a break anyway.

Re: Why Julia

#57

Post by dnautics »

Datenstrom wrote: post #8

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…

Yeah, I built several libraries that replace IEEE floating points with alternatives. You should really be using modules to organize your code. I don't know who told you that they are more trouble than they are worth.

I would also suggest aggressively unit testing all the parts. Numerical developers are not often in that habit, which is a shame.

https://github.com/REX-Computing/unumjl

https://github.com/interplanetary-robot/SigmoidNumbers

Re: Why Julia

#58

Post by kgwgk »

FabHK wrote: post #54
kgwgk wrote: post #46

Earlier quoted context omitted.

I know. But I don't think that's the correct (floating point) result most people would expect, so it's worth signaling. julia> 2^62 4611686018427387904 julia> 2^63 -9223372036854775808 julia> 2^64 0

To be fair, though, this behaviour (namely, staying close to machine arithmetic) has been discussed and decided upon, and advertised. It's what enables the speed. C/C++ makes the same choices, by and large.

I don't think C/C++ have integer exponentiation so even C/C++ programmers may be surprised here. I don't know if the behaviour of the power operator when both numbers are integers (and depending on whether the exponent is negative or positive) is mentioned in the documentation.

Re: Why Julia

#59

Post by improbable22 »

masklinn wrote: post #48
ChrisRackauckas wrote: post #25

Earlier quoted context omitted.

A lot of this blog post is addressed by just using `import` instead of `using`... so it was actually just an issue of not reading the manual. It's like using `from package import *` and then complaining Python doesn't namespace properly.

> 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 does a great job of explaining this right now, import vs. using also changes the rules around adding methods to functions, and it is perhaps more confusing than it has to be.

Re: Why Julia

#60

Post by dnautics »

alanfranzoni wrote: post #32
pron wrote: post #12

Earlier quoted context omitted.

Julia is not statically typed, at least not in the common sense of the term.

Yes, I got that. But the "good parts" according to this artcle derive from where it can work like a statically typed language.

Yeah but it's not statically typed. Let's say you have a machine learning algorithm and you'd like to change your algorithm to have a complex-valued weights instead of float valued weights. How do you do that in a statically typed language?

Let's say you want to test the numerical performance of the fast Fourier transform using an alternative datatype to IEEE 754 (for example bfloat8). How do you do that?

Another application:. I wanted to play with galois fields for reed Solomon encoding. One key step is LU decomposition to recover missing data. Well, as it turns out built-in matrix solving algorithm in Julia is general, (though it does kick over to BLAS for floats), so my galois field type was plug and play, I didn't have to write a custom solver.

Post reply on HN