Show HN: New IDE and GUI for R language(fasterstat.com)
fasterstat.com
Show HN: New IDE and GUI for R language
http://fasterstat.com
23 comments
Good ide
Making R available from Excel seems a good idea to ease the transition for newbies (like R commander) but what advantages does the standalone IDE have over RStudio or the default R.app?
Edit: actually I managed to click through to find this screenshot: http://fasterstat.com/Images/Desktop/12_R_gui.png which looks novel (can't currently watch the video unfortunately)
Edit: actually I managed to click through to find this screenshot: http://fasterstat.com/Images/Desktop/12_R_gui.png which looks novel (can't currently watch the video unfortunately)
A major use-case for Excel integration is in finance, where a vast number of analysts - not newbies in any meaningful sense - work in Excel. Giving them access to the power of R from within a familiar environment is a great thing.
Recommendation for the developer (if you're not doing this already): market hard to finance businesses. You'll make a killing.
Recommendation for the developer (if you're not doing this already): market hard to finance businesses. You'll make a killing.
Term newbies in R was what the poster before stated.
Personally I would NOT want to have anyone use R with a spreadsheet program.
1) I want manipulated data that is clear to replicate
2) I want my output to be plots and reports not another spreadsheet
Personally I would NOT want to have anyone use R with a spreadsheet program.
1) I want manipulated data that is clear to replicate
2) I want my output to be plots and reports not another spreadsheet
> 2) I want my output to be plots and reports not another spreadsheet
Knitr for the win! Seriously great package (and integrated nicely into R Studio), I use it for all my reports, presentations, etc...
Knitr for the win! Seriously great package (and integrated nicely into R Studio), I use it for all my reports, presentations, etc...
I'm finding myself loving org-babel more and more. I also love knitr, but in comparison org-babel:
- Works with just about any language you can imagine, not just R or the few other hypothetically supported languages
- Allows me to write in a lightweight Markdown-comparable, LaTeX-augmentable syntax, except org-mode supports internal references.
- Lets you do truly obscene things like pass values from bash, to python, to julia, to R
As Emacs begins to move more and more to Guile, I hope that the org-* functionality can be instrumented as embeddable libraries. I understand that Emacs isn't for everyone, and thus I wish org-mode (the format) and org-babel were available to the rest of the world. I was surprised to find how few edge-cases aren't better handled by org-* than knitr / RMarkdown.
- Works with just about any language you can imagine, not just R or the few other hypothetically supported languages
- Allows me to write in a lightweight Markdown-comparable, LaTeX-augmentable syntax, except org-mode supports internal references.
- Lets you do truly obscene things like pass values from bash, to python, to julia, to R
As Emacs begins to move more and more to Guile, I hope that the org-* functionality can be instrumented as embeddable libraries. I understand that Emacs isn't for everyone, and thus I wish org-mode (the format) and org-babel were available to the rest of the world. I was surprised to find how few edge-cases aren't better handled by org-* than knitr / RMarkdown.
Agreed. 99% of the time, I only use Excel as a CSV viewer (and it's a rather clunky and error-prone CSV viewer at that).
> A major use-case for Excel integration is in finance, where a vast number of analysts - not newbies in any meaningful sense - work in Excel.
R and Excel integration already exists: http://www.r-bloggers.com/a-million-ways-to-connect-r-and-ex...
Not that I think it's a good idea. Also, R is already a thing in Finance, quite a few job postings list it as a useful skill, and Linkedin has R/Finance groups.
Anyhow, it's much easier to manipulate data with scripts than spreadsheets, especially with R packages like quantmod. Looking at giant spreadsheets makes my eyes bleed and my head hurt, plus I think R Studio makes more sense for newbies to R anyway (and R Studio Server is fantastic for businesses).
R and Excel integration already exists: http://www.r-bloggers.com/a-million-ways-to-connect-r-and-ex...
Not that I think it's a good idea. Also, R is already a thing in Finance, quite a few job postings list it as a useful skill, and Linkedin has R/Finance groups.
Anyhow, it's much easier to manipulate data with scripts than spreadsheets, especially with R packages like quantmod. Looking at giant spreadsheets makes my eyes bleed and my head hurt, plus I think R Studio makes more sense for newbies to R anyway (and R Studio Server is fantastic for businesses).
graphical user interface for selected packages/functions, support for multiple monitors,...
Both sound good, maybe you could highlight these on your landing page? The picker for RColorBrewer palettes looks particularly handy!
Yes you're right. It's the plane.
Typos on page: univerties
FasteR - desctop application
This tools hepls
or as [an] application
FasteR - desctop application
This tools hepls
or as [an] application
There are several other typos which, whilst trivial, are quite jarring:
http://fasterstat.com/Product produsing -> producing poverfull -> powerful
http://fasterstat.com/ anoher -> another
There is also inconsistent use of 'Addin' and 'Add-In'.
http://fasterstat.com/Product produsing -> producing poverfull -> powerful
http://fasterstat.com/ anoher -> another
There is also inconsistent use of 'Addin' and 'Add-In'.
The video presents version 1.4.1 (last 10 seconds of the video), the website only lists version 0.4.1. I assume you changed the version number after finishing the video?
It was hard/impossible for me to read the R code in the video while playing it at 1080p.
It was hard/impossible for me to read the R code in the video while playing it at 1080p.
I'm not a big fan of Excel as IDE for R.
So down vote when someone says. I am not a fan of Excel? I can list several.
1) Excel your end result can not be replicated
2) Excel use in most shops use macros extensively and it is easy to not have your Excel environment available
3) The graphing capabilities of Excel is the reason why people still use pie charts
4) When doing analysis you want everything scripted? Excel as part of the tool chain is not something scriptable.
5) People usually have bad workflows with Excel and it takes learning R or Padas or Matlab or another statistics language to leave their current mindset
6) I can't think of one added benefit for having Excel as part of a good practice workflow unless you are mandated to produce some Excel spreadsheets which R can also do without touching Excel
I could keep going on....
1) Excel your end result can not be replicated
2) Excel use in most shops use macros extensively and it is easy to not have your Excel environment available
3) The graphing capabilities of Excel is the reason why people still use pie charts
4) When doing analysis you want everything scripted? Excel as part of the tool chain is not something scriptable.
5) People usually have bad workflows with Excel and it takes learning R or Padas or Matlab or another statistics language to leave their current mindset
6) I can't think of one added benefit for having Excel as part of a good practice workflow unless you are mandated to produce some Excel spreadsheets which R can also do without touching Excel
I could keep going on....
[deleted]
Really constructive comment- and it was very easy to guess the 9 points you wanted to mention why it's not a good choice.
I used Excel to do some basic data analysis tasks to see whether it is a reasonable alternative to using a statistical package for the same tasks.
Excel is a poor choice for statistical analysis beyond textbook examples, the simplest descriptive statistics, or for more than a very few columns. The problems I encountered that led to this conclusion are in four general areas:
[1] Missing values are handled inconsistently, and sometimes incorrectly.
[2] Data organization differs according to analysis, forcing you to reorganize your data in many ways if you want to do many different analyses.
[3] Many analyses can only be done on one column at a time, making it inconvenient to do the same analysis on many columns.
[4] Output is poorly organized, sometimes inadequately labeled, and there is no record of how an analysis was accomplished.
'Here’s an example of how the numerical inaccuracies in Excel can get you into trouble.'
http://pages.stern.nyu.edu/~jsimonof/classes/1305/pdf/excelr...
As someone previously mentioned here 'RStudio' is great. I would also add R-Project for Linux distribution.
Excel is a wonderful tool for many things. Statistics is not among them.
P.S. Happened a couple of times that articles posted on 'Journal of Econometrics' was denied (even by college students) for errors due to Excel.
Excel is a poor choice for statistical analysis beyond textbook examples, the simplest descriptive statistics, or for more than a very few columns. The problems I encountered that led to this conclusion are in four general areas:
[1] Missing values are handled inconsistently, and sometimes incorrectly.
[2] Data organization differs according to analysis, forcing you to reorganize your data in many ways if you want to do many different analyses.
[3] Many analyses can only be done on one column at a time, making it inconvenient to do the same analysis on many columns.
[4] Output is poorly organized, sometimes inadequately labeled, and there is no record of how an analysis was accomplished.
'Here’s an example of how the numerical inaccuracies in Excel can get you into trouble.'
http://pages.stern.nyu.edu/~jsimonof/classes/1305/pdf/excelr...
As someone previously mentioned here 'RStudio' is great. I would also add R-Project for Linux distribution.
Excel is a wonderful tool for many things. Statistics is not among them.
P.S. Happened a couple of times that articles posted on 'Journal of Econometrics' was denied (even by college students) for errors due to Excel.
It's hard to compete with RStudio for best IDE for R. I stick with vim-R-plugin for most stuff but RStudio is so helpful for making presentations. But competition is good.
Excel add-on, on the other hand, seems very interesting. I lost lots of time in Excel before I decided to get rid of it instead in favour of R+SQLite. I wonder if it would be possible to make the add-on work under wine though.
Edit: just tried to get FasteR add-on under wine. Unfortunately, it requires .NET 4.5 with which I didn't have much success previously...
Excel add-on, on the other hand, seems very interesting. I lost lots of time in Excel before I decided to get rid of it instead in favour of R+SQLite. I wonder if it would be possible to make the add-on work under wine though.
Edit: just tried to get FasteR add-on under wine. Unfortunately, it requires .NET 4.5 with which I didn't have much success previously...
The latest RStudio preview release has Vim mode, if you're interested.
The Vim mode in RStudio is rather disappointing. Doesn't even have support for macros.
It does now, in RStudio's public preview release: http://blog.rstudio.org/2015/02/23/rstudio-0-99-preview-vim-...
Thank you for making it free for non-commercial use! This is very useful.
Is the FasteR IDE or any other equivalent command line utility available for Linux distributions ?
FasteR is available only for Windows. But for Linux you can use for example R Studio (mature tool compared to FasteR).
Are there any ideas on making it opensource ?
Yes, in the case of fail as startup :)
You mention "For using FasteR you need fit only several conditions", while it's only Windows and .Net. "Several" makes it sounds like a difficult installation and may prohibit some novices to install it.
And yet they keep that butt-ugly logo. Is it an in-joke, or something?
It actually kind of is. GNU logos are consistently incredibly ugly and show utter disdain for, or lack of awareness of, graphical design [0].
It could be almost like a philosophical point: "GNU software is utilitarian. We don't waste time on fancy graphics". Or it could be that GNU developers tend to be... developers. No designers in sight, and no appreciation for visual aesthetics.
0: https://www.gnu.org/graphics/package-logos.html
It could be almost like a philosophical point: "GNU software is utilitarian. We don't waste time on fancy graphics". Or it could be that GNU developers tend to be... developers. No designers in sight, and no appreciation for visual aesthetics.
0: https://www.gnu.org/graphics/package-logos.html
> GNU logos are consistently incredibly ugly
True, but since it's Free Software you can release a version of the same code by yourself with a better logo. Nobody prevents you from changing anything, that's what's beautiful with GNU tools.
True, but since it's Free Software you can release a version of the same code by yourself with a better logo. Nobody prevents you from changing anything, that's what's beautiful with GNU tools.
And these aren't just developers. They're also *statisticians".
I really miss the old Python snake logo.
Are people still using windows?
http://www.netmarketshare.com/operating-system-market-share....
As do I. It serves as a fine basic computational substrate for the kind of stuff I do, mostly hassle free.
As do I. It serves as a fine basic computational substrate for the kind of stuff I do, mostly hassle free.
Interesting product.
However, you should get a native English speaker to fix the grammar and spelling on your web site.
At least they didn't spell it "FastR".
Beware the IDEs of March!
Oy. And yet, I couldn't stop myself from upvoting this comment. You made this day a touch better.
Interesting indeed! especially the Excel part!
I don't understand why people would want to do mathematics in imperative languages.
(Yes, I understand imperative languages are faster, but why not just keep the imperative parts for the "inner loops", nicely isolated, and a functional core for everything else?)
(Yes, I understand imperative languages are faster, but why not just keep the imperative parts for the "inner loops", nicely isolated, and a functional core for everything else?)
> I don't understand why people would want to do mathematics in imperative languages.
R isn't exactly what I'd call your typical imperative language. It's more like the love child of APL and Scheme, with random bits thrown in by a bunch of statisticians.
Loops are almost never used in R, since pretty much everything is a vector (or some sort of data structure made of vectors), you simply apply functions to vectors and it maps over the whole thing.
Of course, the C, C++ and Fortran bits are 'imperative', which is kind of the structure you describe anyway (functional, vectorized R language which calls down to a bunch of C/Fortran functions).
R isn't exactly what I'd call your typical imperative language. It's more like the love child of APL and Scheme, with random bits thrown in by a bunch of statisticians.
Loops are almost never used in R, since pretty much everything is a vector (or some sort of data structure made of vectors), you simply apply functions to vectors and it maps over the whole thing.
Of course, the C, C++ and Fortran bits are 'imperative', which is kind of the structure you describe anyway (functional, vectorized R language which calls down to a bunch of C/Fortran functions).
R does support functional programming. In fact, it was based on Scheme (see discussion for comparison: https://stat.ethz.ch/pipermail/r-help/2008-December/181982.h...).
They're easier and faster to develop in. Remember that the scripts usually only need to be run once - maintainability is irrelevant.
I don't think this all of the difficulty is intrinsic to FP, but FP language designers don't usually care about newbie-friendliness. The closest thing to a user-friendly FP language I know about is Scala, and it, too, has lots and lots of arbitrary symbols and hideously complicated function signatures.
Remember, the typical scientist has no patience for monads, currying, inscrutable value names or functions-as-arguments and compiler complaints about function signatures are more likely to instill deep hatred than anything else.
I know it's an extreme example, but a statistician will never try to understand what something like "def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That" means, he'll just move on to a language that's easier.
I don't think this all of the difficulty is intrinsic to FP, but FP language designers don't usually care about newbie-friendliness. The closest thing to a user-friendly FP language I know about is Scala, and it, too, has lots and lots of arbitrary symbols and hideously complicated function signatures.
Remember, the typical scientist has no patience for monads, currying, inscrutable value names or functions-as-arguments and compiler complaints about function signatures are more likely to instill deep hatred than anything else.
I know it's an extreme example, but a statistician will never try to understand what something like "def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That" means, he'll just move on to a language that's easier.
R is, at its core, a functional language with a bunch of largely optional imperative bits bolted on.
One of R's great current evangelists, Hadley Wickham, is taking it back to its functional roots[1](http://cran.rstudio.com/web/packages/dplyr/vignettes/introdu...) as well.
See also http://github.com/hadley/purrr
Unfortunately, the R language isn't fast, especially not the imperative features (loops). A language like Julia is a better bet in that respect.
The drawcard of R is the breadth of specialised statistical packages. (Often with inner loops written in C for performance.)
The drawcard of R is the breadth of specialised statistical packages. (Often with inner loops written in C for performance.)
in R loops are generally frown upon due to this issue.
BUT R is not slow when it comes to parallel processing or using Revolution Anayltics also has speed ups if you need it. R also has dplyr is speedy and the data.tables is even faster. I think the original Julia speed claims were a little biased to Julia and well there is plenty of awesome things about R, but "slow" isn't a far statement. There is a reason why R has grown so much.
Interesting argument for R usage: https://matloff.wordpress.com/2014/05/21/r-beats-python-r-be...
BUT R is not slow when it comes to parallel processing or using Revolution Anayltics also has speed ups if you need it. R also has dplyr is speedy and the data.tables is even faster. I think the original Julia speed claims were a little biased to Julia and well there is plenty of awesome things about R, but "slow" isn't a far statement. There is a reason why R has grown so much.
Interesting argument for R usage: https://matloff.wordpress.com/2014/05/21/r-beats-python-r-be...
"R is slow" refers to the main implementation of the language --- to code written in R --- and is completely fair. The packages you're talking about are mostly written in C or C++ with nice R interfaces. So R as a statistical package or R from a user's perspective is often quite fast, but that's because it is relatively easy to interface with C and C++.
(This comes up often, and I'm not sure why I'm compelled to reply today, but there it is.)
(This comes up often, and I'm not sure why I'm compelled to reply today, but there it is.)
But MANY programming languages work this way. I would say that coding in R it doesn't matter if it is C or Fortan why say programming in R is slow even though in practice it really isn't with some new solutions?
Many languages are slow. (Or, more concretely, many languages have only slow implementations.) If C or Fortran interfaces are easy, speeding up the language shouldn't necessarily be a priority. But that doesn't make the language itself fast.
As for why this can matter: a big part of my job is designing and prototyping new statistical estimators. "Prototyping" means running them through lots of simulations to explore their properties in small samples. My two options in R are:
1. Program up the estimator in pure R, in which case the simulations can take days to weeks to complete.
2. Program up the estimator in C and write an R interface, in which case the simulations will run 10 to 100 times faster. (Depending on the exact operations used.) The code will take much longer to adjust if I need to change the estimator, which happens frequently, and debugging will take longer.
3. Program up the estimator and simulations in pure C, making it still faster but much more brittle.
This is a fairly iterative process -- I'll typically discover errors in the math as I run the simulations or after I've run them, or the simulations will reveal unappealing properties that need to be fixed. But once I have "good" estimator and "good" simulations, I write it up in a paper and am done with it. (Gross simplification of my actual job, but accurate enough.)
So the distinction between "R's speed" and "C's speed" very much matters, and if R were actually as fast as C it would make my life much easier.
Of course, for people who are "coding in R" by running data analysis in a script the distinction doesn't matter. But I already said that in the comment you're replying to.
As for why this can matter: a big part of my job is designing and prototyping new statistical estimators. "Prototyping" means running them through lots of simulations to explore their properties in small samples. My two options in R are:
1. Program up the estimator in pure R, in which case the simulations can take days to weeks to complete.
2. Program up the estimator in C and write an R interface, in which case the simulations will run 10 to 100 times faster. (Depending on the exact operations used.) The code will take much longer to adjust if I need to change the estimator, which happens frequently, and debugging will take longer.
3. Program up the estimator and simulations in pure C, making it still faster but much more brittle.
This is a fairly iterative process -- I'll typically discover errors in the math as I run the simulations or after I've run them, or the simulations will reveal unappealing properties that need to be fixed. But once I have "good" estimator and "good" simulations, I write it up in a paper and am done with it. (Gross simplification of my actual job, but accurate enough.)
So the distinction between "R's speed" and "C's speed" very much matters, and if R were actually as fast as C it would make my life much easier.
Of course, for people who are "coding in R" by running data analysis in a script the distinction doesn't matter. But I already said that in the comment you're replying to.
Thank you for actually replying and clarifying your statement, I enjoy learning different ways of thinking. I guess I am changing my word for R to "Fast Enough for Me." I can run my scripts in under 20 seconds, but a few years ago it could be 2 or 3 minutes.
R is slow if you try to use it like an imperative language. If you use it idiomatically, it's quite fast. If all the intensive data-processing calls functions written in C/Fortran, it's very fast. And of course, you can use R for parallel processing, or in a cluster...
Julia as a language is faster, but I'm not sure it's actually faster than R to process data if you're using R as most people do...
Julia as a language is faster, but I'm not sure it's actually faster than R to process data if you're using R as most people do...
Windows only ? Meh. And integrating with Excel is completely useless (and meaningless, since you don't need to use a spreadsheet representation to work with data when you think in R), R beats Excel for about everything once you are used to it.
I was also looking for an OS X / Linux version. The website doesn't mention being Windows only, will other operating systems be supported in the future?
What happens when you just download FasteR? Does it work for a limited period and then stop working, will it ask me for a license each time I start it?
Also, why would I pay €399 for FasteR while its main competitor is more mature and completely free? Aside from Excel add-in, the two other reasons I've found are in the comments here: "graphical user interface for selected packages/functions, support for multiple monitors". Am I missing something?
Also, why would I pay €399 for FasteR while its main competitor is more mature and completely free? Aside from Excel add-in, the two other reasons I've found are in the comments here: "graphical user interface for selected packages/functions, support for multiple monitors". Am I missing something?
Current version of software show you info about licensing options (if you have it without license ID).
399 is for both editions of software for next two years. There are multiple reasons not only two... Mainly the GUI, but this is not in current 0.4.1 version available in the form as I imagine. I only follow the advice: Release something before you are satisfied.
399 is for both editions of software for next two years. There are multiple reasons not only two... Mainly the GUI, but this is not in current 0.4.1 version available in the form as I imagine. I only follow the advice: Release something before you are satisfied.
[deleted]
[deleted]
I love, love, love the excel integration. Fantastic.
I urge you to make a Chocolatey package to make updating easy.
There's also a lot of low-hanging fruit in terms of usability. e.g. the objects browser should automatically refresh when you "transfer data". Also I'd love to be able to make "transfer data" use a data.table instead of data.frame.
Killing the R process then hitting refresh on the object browser results in a crash.
I urge you to make a Chocolatey package to make updating easy.
There's also a lot of low-hanging fruit in terms of usability. e.g. the objects browser should automatically refresh when you "transfer data". Also I'd love to be able to make "transfer data" use a data.table instead of data.frame.
Killing the R process then hitting refresh on the object browser results in a crash.
You really can't be bothered to at least `aspell` your website?
[deleted]
This has been done before. An R Gnumeric plugin is a thing, and there's been Excel plugins before as well.
I personally use R Studio and see no reason why I'd prefer a spreadsheet, R Studio does let you see a table representation of data anyway, and can very easily import spreadsheets and manipulate them.
I personally use R Studio and see no reason why I'd prefer a spreadsheet, R Studio does let you see a table representation of data anyway, and can very easily import spreadsheets and manipulate them.
- I think that developing software for “Windows only” is not a mistake. If you make the first version with a small team or in one person, it removes a lot of compatibility issues and problems. If the software will be successful on Windows, it can be extended to other platforms. - "It's hard to compete with R Studio" - yes it is true. Therefore, it is necessary to go a little different path. This will be visible later, after several iterations. It is now difficult to compare the first public version of FasteR with mature R Studio. But competition is always a good think. - "Excel is bad" - According to statistics here is a 750M of Excel users. Every statistician knows about problems of Excel (or all spreadsheet tools). On the other hand, it is standard in a number of areas. If you look around (not only in the community of developers and designers) you will find that with Excel spreadsheets works tremendous amount of companies and institutions, particularly because of its simplicity. For some issues is not sufficient and here is it possible to use for example the integration with FasteR.