61–70 of 96 posts
Earlier quoted context omitted.
julia has really good interop with both of python and R as well as cpp, matlab, mathematica and others. Also it's not just about the numbers.
I love Julia, but feel the interop story could use some work. If I want to have my python package depend on some Julia code, how easy is that? Last time I checked (a few months ago), it was pretty difficult.
Earlier quoted context omitted.
I whole heartedly agree. Python is garbage for data science. If an industrial grade NN library was written for it, plus some quant libraries, I think most people would switch. I work in finance doing data science-y things and have yet to meet anyone who doesn’t think that Python is a pile of garbage. People used to make the easy to learn argument, but Julia is even easier. And more elegant, extensible, and faster.
Whenever I see the “I’ve never met x” argument, I’m always looking out for the catch. Because it’s a bad argument to begin with. But the catch is almost always in a situation where x is everywhere , and you would have to have your head willfully stuck in a hole in the ground to not see it. And this is no exception.
Earlier quoted context omitted.
So you're telling us not to waste our time with R or Python... but to constantly interop with R and Python?
I mean if there are packages that you need then be my guest. But like if you are starting a new project, julia is a more productive language.
Source for this, please?
Earlier quoted context omitted.
I mean if there are packages that you need then be my guest. But like if you are starting a new project, julia is a more productive language.
> julia is a more productive language Source for this, please?
Earlier quoted context omitted.
I mean if there are packages that you need then be my guest. But like if you are starting a new project, julia is a more productive language.
> julia is a more productive language Source for this, please?
If you're really going down to the FFI, it's hard to think it wouldn't be more productive, but that's not what a true beginner like the target of this book would do. Though it's quite nice to quickly extend some tool for your purpose without compromising anything or to understand how something works thanks to being written in high level code.
Syntax-wise, Julia's Common Lisp-like feature set gives the language a lot of power, but normal use will probably be just on par with Python in terms of productivity.
I skimmed through the book, and think it does a very poor job at showcasing how R and Python are juxtaposed in industry. To be fair, the book advertises showing R and Python code side-by-side. And that’s what it does. But it does it unlike how the languages are most often used in industry. As a quick example, I saw no tidyverse code, which is essentially the only thing keeping R in the game. Learning R from this book…
Earlier quoted context omitted.
I agree for the most part, but R does have a few things beyond the tidyverse: built-in dataframe support, lots of domain-specific packages, more consistent interfaces for basic statistics and machine learning models, etc. Python is definitely better for matrices (because of NumPy) and anything involving custom gradient descent methods (because of TensorFlow). I think 90% of data science content is for beginners becau…
> Python is definitely better for matrices (because of NumPy) How so?
i only read the chapter on optimization/linear programming - its far too brief and misses key concepts for it to be useful. there are no real applications of the concepts covered in the section.
Earlier quoted context omitted.
I agree for the most part, but R does have a few things beyond the tidyverse: built-in dataframe support, lots of domain-specific packages, more consistent interfaces for basic statistics and machine learning models, etc. Python is definitely better for matrices (because of NumPy) and anything involving custom gradient descent methods (because of TensorFlow). I think 90% of data science content is for beginners becau…
> built-in dataframe support Not an advantage if you ask me - exactly because data.frame is built in, people have been building their own versions (tibble, data.table) instead of improving it. That's how R ended up with 3 different structures that are similar but have inconsistent apis and behaviour. > lots of domain-specific packages That's true. > more consistent interfaces for basic statistics and machine learning…
Python has utility. But R is far superior in its the quality of the packages, their documentation, their ability to behave predictably on a given data type.
I run a machine learning shop. Right now all of the training, application, and data management is handled via R. R is simply superior in too many ways for us to be bothered with python for the scale of work we are doing.
Since we're moving some big applications to keras/ TF we do use python and will be using more in the future. However, for almost all data management, munging, movement visualization, reporting, its an R world.