TidyverseSkeptic VS Transformers.jl

I just don't get these to be honest -- besides the fact that author missed simple things like `df.groupby('var',as_index=False)`, isn't this obviously arbitrary "this is easier my way" complaints? (I did R before all the chaining stuff was popular, and I wouldn't stuff everything into a single command like that even now. It isn't like you get lazy evaluation or any special data processing magic.)

So I get people love chaining and tidyverse, good for you, I don't. But at least I can acknowledge that my way (or this way) people have different preferences and one is not intrinsically easier.

Norm Matloff has a blog where he essentially just argues the opposite of all the tidyverse stuff, https://github.com/matloff/TidyverseSkeptic, but it is the same idea in reverse to me (one is not obviously easier to learn than the other IMO).

On the other hand, there is also a more traditional universe outside of the of the newer tidyverse approach. See the criticism of the tidyverse ecosystem by Prof Norm Matloff (of UC Davis). He provides a freely available introductory course in base R.

Whenever I hear tidyverse, I just feel the need to leave this: TidyverseSceptic

Yeah, I had never heard of him before, but I followed the link in the article above to his GitHub page and think he made some really great points about conciseness and clarity in base R code, and, I admittedly had no idea tapply() was so useful and easy to use, because I almost never see it used in any examples online. Although I agree with others here that he's misrepresenting why package developers use base R (which is to avoid dependences in their packages, which is very important), I also find myself agreeing with him that future R programmers not being taught base R is worrisome (I'm thinking of dependencies in future package development).

I was in an R group meeting. One of the members mentioned Prof. Norm Matloff and said he has comments about tidyverse. I searched and found Matloff's explanation here. What are your thoughts on tidyverse and Matloff's comments about it? As I read it, I found myself agreeing with certain points. I do not have a computer science background; I'm someone trying to learn coding because I see uses for it in my work. I started my learning, about a year ago, with tidyverse tutorials. My patchwork jumping around, maybe in addition to some of the gaps Matloff indicates, show me that I know very little about base R.

There are good arguments against tidyverse, especially for beginners. It doesn't lead to a growth in understanding the language fundamentals and requires to learn many functions, paradigms, and syntaxes not shared by base R, which can easily be overwhelming and lead to a learn-by-heart approach more than to a learn-by-understanding. There are many good articles on the topic, such as this one or a more in-depth one, suggesting to consider tidyverse a more advanced application for specific use cases, if you like the dialect. I don't, so I might be biased.

I would discourage you to get into the tidyverse, at least in the first stages of your R training. It's like trying to learn english AND scottish together as a foreigner. You can read some better worded discussions here https://github.com/matloff/TidyverseSkeptic and here https://towardsdatascience.com/a-thousand-gadgets-my-thoughts-on-the-r-tidyverse-2441d8504433?gi=1b0a3648b6e6

My opinions are largely in agreement with Norm Matloff on the subject actually.

Flux is quite a nice lower level library:

https://github.com/FluxML/Flux.jl

On top of that there are many higher level libraries such as Transformers.jl

https://github.com/chengchingwen/Transformers.jl

Check out Transformers.jl. It’s a library that implements transformer based models in Julia using Flux.jl. They have support for some of the huggingface transformers.

https://github.com/chengchingwen/Transformers.jl but I have not had any personal experience with.

All of this is build by the community and your mileage may vary.

In my rather biased opinion the strengths of Julia are that the various ML libraries can share implementations, e.g. Pytorch and Tensorflow contain separate Numpy derivatives. One could say that you can write an ML framework in Julia, instead of writting a DSL in Python as part of your C++ ML library. As an example Julia has a GPU compiler so you can write your own layer directly in Julia and integrate it into your pipeline.

I think you might have some luck with looking at a transformers implementation in flux, e.g: https://github.com/chengchingwen/Transformers.jl/tree/master/src/basic

Having tried fastai for a "serious" research project and helped (just a bit) towards FastAI.jl development, here's my take:

> motivation behind this is unclear.

Julia currently has two main DL libraries. Flux, which is somewhere between PyTorch and (tf.)Keras abstraction wise, and Knet, which is a little lower level (think just below PyTorch/around where MXNet Gluon sits). Frameworks like fastai, PyTorch Lightning and Keras demonstrate that there's a desire for higher-level, more batteries included libraries. FastAI.jl is looking to fill that gap in Julia.

> Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet.

This is correct. That said, FastAI.jl is not and does not plan to be a copy of the Python API (hence "inspired by"). One consequence of this is that integration with other libraries is much easier, e.g. https://github.com/chengchingwen/Transformers.jl for NLP tasks.

> What is the timeline for FastAI.jl to achieve parity?

If NLP primitives are all that's keeping you from testing the waters, have a look at https://github.com/chengchingwen/Transformers.jl.