4 ms·
Past a low complexity bar, I feel like R is a much easier answer than Excel. Excel can get pretty hairy pretty fast. As you mention below, debugging even terrib
by peatmoss 8y ago
Past a low complexity bar, I feel like R is a much easier answer than Excel. Excel can get pretty hairy pretty fast. As you mention below, debugging even terrible R code is easier than debugging Excel.
- ams6110 8y agoReally? I took a stab at R about a year ago and found it utterly confusing.
- bachmeier 8y agoI think the point is that formulas and macros are more utterly confusing.
- patmcguire 8y agoYeah, at least the R code only goes up and down, line by line. Most non-trivial excel code will have different bits of code going right and left (formulas sit in a row,column pair). One you get into extra tabs/sheets that's yet another dimension.
- wyoung2 8y agoThe problem with debugging formula code is that it's hidden in the default view, and you have to know which cells to click on to find each bit of code. In simple spreadsheets, the proper cell to click on is obvious, because the formula only updates the one cell where the formula is. The problem comes with multi-cell functions like Excel's VLOOKUP or Google Sheets' QUERY, where a cell that looks like it contains literal text might contain the complex formula call, and then all of those around it might look like plain text, but they're also the call's results. Editing any of this wrecks the sheet. Despite these dangers, I recently perpetrated such a thing in Google Sheets, because that's the only platform I could get to easily work across many sites, some of which have users that are often offline. The next step up from that would be to stand up a custom web app, and the project simply did not demand that amount of effort. The next-best idea was to keep passing around .xls files via email; barf. That's the seductive nature of these one-off spreadsheet "apps": they're quick and easy to stand up, yet difficult to extend and debug by the time that they grow to the point where they would justify development time for a proper application. By then, they've also gained a big enough user base and feature set that rebuilding the app properly also means a big effort in all axes: development, testing, deployment, and retraining.
- peatmoss 8y agoI’ve taught R (and Python) to mostly non-programmer scientists as part of multi-day Software Carpentry workshops. Especially with R, I feel like most attendees after a couple of days were able to do things that would be decidedly non-trivial in Excel. EDIT: emphasis on my original point of “past a low complexity bar.” If someone is looking to manually enter data and maybe sum a row or two, Excel is probably easier. I’d say at the point where someone needs to reshape data or do any kind of non-trivial formula, R becomes easier—certainly easier for me to imagine teaching.
- roel_v 8y agoIt is. It's convoluted and idiosyncratic for no reason and all together a puzzled together mess. R is not (much) better than Excel. It's better in the same way that getting stabbed in the eye with a hot poker twice is better than getting stabbed with it three times.
- FranzFerdiNaN 8y agoAs a non-programmer (my job is in business intelligence so the most “programming” I do is in sql) I found R really easy to understand and use. Within hours of starting with it I was already doing part of my job in it, especially thanks to Tidyverse libraries. I did once try to learn Java, which I did found incredibly confusing and impossible to do anything useful with.
- __blockcipher__ 8y agodo you mind if I derail the thread for a little bit? [if yes] I currently work at a small-medium sized company, and we have one BI guy. Our ops team is ~5 people, and 1-2 of the more junior guys are tasked with doing everything necessary to support the BI guy. which basically means making sure the BI software is installed properly on the container, configured properly, has access to the db, and it comes up properly etc BI is a critical business function, so it's a pretty high priority, but the process is way less automated and skillfully crafted than the other parts of the system, mainly cause everyone hates it and only barely understands what the BI system (in this case, pentaho) actually does. it's no coincidence that the most junior engineers often end up doing it (with occasional but pretty infrequent help from the seniors when blocked) what i've been wondering is, what exactly does "a BI guy" need their system to do? I read a bit about ETL systems, but haven't done much research. I assume the job of an ETL system is to pull data from the production database(s), clean it up as necessary, and use that data to calculate whatever business metrics are required? is the software more about making it easy for the BI team to use an interface to craft their queries/dataflow/etc? basically my motivation is I've mulled over the idea of having the ETL system be written in-house. the benefits being potentially smoother and more native operation and in a way that's more seamless to integrate with monitoring, alerting, automated jobs etc. my guess is that such a project would end up being a waste of time in 98% of cases, especially because you need a usable frontend for the BI guy. so, if I may, what exactly is business intelligence / what do you do on a day-to-day basis? I'm pretty experienced with traditional finance/investing jobs, eg reading 10-q's, 10-k's, balance sheets etc, and using the data to calculate cash flow, opex, gross margin, and every other metric you could conceivably want. But I'd never heard of "business intelligence" until starting an internship several months ago. thanks, and no worries if you don't have time to respond / if this is too off-topic.