Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
This page is experimental. Here we collect the fringe public comments related to data.table, in date order. Fringe in the sense of peripheral or extreme but also subtle. These can often go quietly viral and gently sway a community over time. For those for who English is not their first language, sarcasm and jest are powerful tools sometimes on display here. We have always added all articles we are aware of to the articles page if they mention data.table (whether positive or negative) and will continue to do so. Even so, the sentiment of the articles page is overwhelming positive. The goal of this fringe page is to collect public comments (anything that is not an article, since that belongs on the articles page) with a bias towards the negative to aid potential new users in their quest to build a full unbiased picture of the data.table package.
Or, in other words, a problem shared is a problem halved.
or do it in a slower, but more readable way with dplyr
great to hear, that'll be simple to switch to dplyr::right_join() or whatever
Both were responses to Hugh Parsonage using data.table at Grattan Institute (see the threads on Twitter). The results were quoted several times in this Question Time article; i.e. a success for data.table that Matt Cowgill sought to shoot down. He has 7,600 followers at this time, more than twice mine. It's these kind of side-remarks that work very well and sway a community. Unless we spend more time demonstrating how rolling join was used and showing 2 secs vs 30 mins, the community will believe the more popular people speaking out against data.table, like Matt Cowgill. I filed issue 2862 to write up this work and compare and contrast to alternatives.
Wickham: one of the reasons data.table is much faster than dplyr is because everything is modified in place, which gives me the heebie-jeebies
I think the other bit is that data.table does (despite what some tribal members posit) whack some of the extract (i.e. , []) idioms. So some "data.frame" syntax does not work & causes confusion. That bit me when making widgets. I always normalize widget df input to data.frame
data.table is 👍 if you really need munging speed in R & can tolerate unreadable hieroglyphics. I’ll take tidyverse + ops in DBs any day.
To weigh any opinion you need to know what they do to know whether they do a similar thing to what you do and what their motivations are, first, before looking at the details of the claim. I have previously replied regarding the tribal adjective here on his article and here on twitter. Since he knows this is troubling to me, he continues to use the word to taunt. The derogatory tribal adjective is an ad hominem attack.
Use data.table for wrangling data without the ugly data.table syntax https://cran.r-project.org/web/packages/dataPreparation … #rstats
It doesn't feel good for your work to be called "ugly". My only response was to retweet it so that others see it and help/suggest. To engage to disagree (of course I disagree strongly) will waste time and likely end badly. To not engage leaves negative sentiment others will find. I have no idea how to handle people who use such hateful words for any work, let alone work that is offered freely.
Collaborating with someone who uses data.table. My loyalty to the #tidyverse grows greater by the second... cc @hadleywickham #rstats
This was copied to #rstats, retweeted by Hadley and intended to be widely seen. It is not pleasant to be denied the knowledge of why you're being criticized publicly. Unfortunately, this tactic does work and it does sway a community. Perhaps the tweeter or his collaborator have misunderstood something; we will never know. Replying to ask risks escalating and taking even more time. Time I can't make.
My response was to retweet this one from earlier in the month. I hadn't felt it was appropriate to retweet that before. Silly, isn't it.
8 April 2017 Thọ Duy Nguyễn on Twitter
back to data.table after a long time with dplyr #rstats
Data tables are extremely fast but I think their concision makes it harder to learn and code that uses it is harder to read after you've written it. It's very reminiscent of APL.
Our response: See the hacker news item and comparing dplyr to data.table on Stack Overflow.
The word reminiscent was used to convey the notion of-the-past and is meant as criticism. Note that Hadley was responding to a positive post about data.table on Hacker News. The original item was :
Anyone doing R comparisons should use data.table instead of data.frame. More so for benchmarks. data.table is the best data structure/query language I have found in my career. It's leading the way in The R world, and in my way, in all the data-focused languages.
Hadley sought to shoot down this positive sentiment. His negative sentiment is what has stuck in the community rather than the original post which was positive. That's what works.
Also read.csv() reads everything into a big character matrix and then modifies that, does fread() do the same thing? In fastread we guess column types and then coerce as we go to avoid a complete copy of the df.
The Stack Overflow question is "Reason behind speed of fread in data.table package in R" and an implicit compliment to data.table. That's the context. The comment is a subtle way to i) create doubt about
fread and ii) announce his new
fastread package which had not been known before that.
fastread subsequently became