Guys, What's you're opinion on Julia?
I am thinking of using it for data science work.
Any draw backs? or advantages I should know about?
Lenses in Julia
21–30 of 68 posts
Re: Lenses in Julia
#22Guys, What's you're opinion on Julia? I am thinking of using it for data science work. Any draw backs? or advantages I should know about?
If you’re young, new to data science and hoping to get a job in it after some time, then I absolutely recommend learning Python instead of Julia.
But if you are just interested in learning a new language and trying it in data science OR are not currently looking to enter the data science job market, then by all means: Julia is great and in many ways superior to Python for data science.
It’s just that «everyone» is doing data science in Python, and if you’re new to DS, then you should also know Python (but by all means learn Julia too!).
Re: Lenses in Julia
#23Guys, What's you're opinion on Julia? I am thinking of using it for data science work. Any draw backs? or advantages I should know about?
I've worked in about 40 languages and have a Ph. D. in the subject. Every language has problems, some I like, some I'm not fond of
There is only one language that I have an active hatred for, and that is Julia.
Imagine you try to move a definition from one file to another. Sounds like a trivial piece of organization, right?
In Julia, this is a hard problem, and you can wind up getting crashes deep in someone else's code.
The reason is that this causes modules that don't import the new file to have different implementations of the same generic function in scope. Julia features the ability to run libraries on data types they were never designed for. But unlike civilized languages such as C++, this is done by randomly overriding a bunch of functions to do things they were not designed to do, and then hoping the library uses them in a way that produces the result you want. There is no way to guarantee this without reading the library in detail. Also no kind of semantic versioning that can tell you when the library has a breaking change or not, as almost any kind of change becomes a potentially-breaking change when you code like this.
This is a problem unique to Julia.
I brought up to the Julia creators that methods of the same interface should share common properties. This is a very basic principle of generic programming.
One of them responded with personal insults.
I'm not the only one with such experiences. Dan Luu wrote this piece 10 years ago, but the appendix shows the concerns have not been addressed: https://danluu.com/julialang/
Re: Lenses in Julia
#24I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
This is equivalent to that for people who are irrationally terrified of mutability, and are willing to abandon performance.
Immutability gives you persistence, which can be practically useful. It’s not just fear.
Re: Lenses in Julia
#25Guys, What's you're opinion on Julia? I am thinking of using it for data science work. Any draw backs? or advantages I should know about?
I've worked in about 40 languages and have a Ph. D. in the subject. Every language has problems, some I like, some I'm not fond of There is only one language that I have an active hatred for, and that is Julia. Imagine you try to move a definition from one file to another. Sounds like a trivial piece of organization, right? In Julia, this is a hard problem, and you can wind up getting crashes deep in someone else's c…
I guess you had a bad experience, but this hasn’t been an issue for me using it for many years now.
Re: Lenses in Julia
#26Guys, What's you're opinion on Julia? I am thinking of using it for data science work. Any draw backs? or advantages I should know about?
I don’t use it for much data science, and I only have used it for one project (to speed up my dad’s Octave code), but I actually really liked it. Generally speaking things were extremely fast, even without any specific optimization on my end. Like, without hyperbole, a direct port of my dad’s code was between 50-100x faster in most cases, and when I started optimizing it I ended up getting it going about 150x faster.
There was a bit of weirdness with the type system with its dynamic dispatch making things slow, but specifying a type in function headers would resolve those issues.
I also thought that the macro system was pretty nice; for the most part I found creating custom syntax and using their own helpers was pretty nice and easy to grok.
Since I don’t do much data work I haven’t had much of an excuse to use it again, but since it does offer channels and queues for thread synchronization I might be able to find a project to use it for.
Re: Lenses in Julia
#27I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
The difference doesn't matter when you have a shallow structure and can access fields directly and have a few lines of code. But field access does not compose easily if you have a nested hierarchy of objects. Your natural choice in the "OOP style" is to write a lot of boiler plate to point to each different field you want to get/set. Say you get bored of the tedium and want "higher-order" accessors that compose well…
> Your natural choice in the "OOP style" is to write a lot of boiler plate to point to each different field you want to get/set.
Your natural alternative to lenses in imperative languages is usually to just store a reference or pointer to the part you want to modify. Like a lens, but in-place.
Re: Lenses in Julia
#28I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
This is equivalent to that for people who are irrationally terrified of mutability, and are willing to abandon performance.
Counterintuitively Julia recommends the use of immutable data types for performance reasons, because immutability enables more flexible compiler optimisations
An immutable variable can be savely shared across functions or even threads without copying. It can be created on the stack, heap or in a register, whatever the compiler deems most efficient.
In the case, where you want to change a field of an immutable variable (the use case of lenses), immutable types may still be more efficient, because the variable was stack allocated and copying it is cheap or the compiler can correctly infer, that the original object is not in use anymore and thus reuses the data of the old variable for the new one.
Coming from the C++ world, I think immutability by default is pretty need, because it enables many of the optimisations you would get from C++'s move semantics (or Rust's borrow checker) without the hassle.
Re: Lenses in Julia
#29Guys, What's you're opinion on Julia? I am thinking of using it for data science work. Any draw backs? or advantages I should know about?
I've worked in about 40 languages and have a Ph. D. in the subject. Every language has problems, some I like, some I'm not fond of There is only one language that I have an active hatred for, and that is Julia. Imagine you try to move a definition from one file to another. Sounds like a trivial piece of organization, right? In Julia, this is a hard problem, and you can wind up getting crashes deep in someone else's c…
I don't quite understand what your issues were, I don't have any with the current module system https://docs.julialang.org/en/v1/manual/modules/
Can you provide some concrete examples of that issues existing today?
Re: Lenses in Julia
#30Guys, What's you're opinion on Julia? I am thinking of using it for data science work. Any draw backs? or advantages I should know about?
As a language, Julia is strictly superior to Python in many ways (e.g., it's easy to write multithreading code). Currently Python still can be preferable due to its huge ecosystem and super optimised libraries for data science. But Julia is catching fast.