In most lists of the most popular software for doing data analysis, statistics, and predictive modeling, the top software tools are Python and R—command line languages rather than GUI-based modeling packages. There are several reasons for this, perhaps most importantly that they are free, they are robust programming languages supported by a very broad user community, and they have extensive sets of algorithms.
One recent survey of software was published at r4stats.com (http://r4stats.com/articles/popularity/) and contains additional metrics not usually found in software comparisons, including scholarly articles that include software, google scholar hits, and job trends in addition to the more typical summaries by user-identified use of software such as with the Rexer Analytics surveys (http://www.rexeranalytics.com/Data-Miner-Survey-Results-2013.html) and polls on kdnuggets.com and reviews of software by technology research companies such as Gartner (http://pages.alteryx.com/GartnerMQAdvancedAnalyticsNowAvailable-T.html), Forrester (http://global.sap.com/campaign/na/usa/CRM-XU13-BIP-PATDWS/index.html?urlid=CRM-XU13-BIP-PATDWS), and Hurwitz & Associates (http://www.sas.com/content/dam/SAS/en_us/doc/analystreport/hurwitz-advanced-analytics-107212.pdf). Thanks to r4stats for providing these links in their article.
For those interested in getting a job in analytics, the article provides very useful rankings of software by the number of job postings, led by Java, SAS, Python, C/C++/C#, R, SPSS, and Matlab. They also provide a few examples of the trending in the job postings of the tools over the past 7 years—important trending to consider as well. This reveals for example a nearly identical increase in Python and R compared with a decrease in SAS over the past few years (SAS is still #2 overall in job postings though because of the huge SAS install base).
The user interface that appears to have won the day in commercial software for predictive modeling is the workflow-style interface where a user connects icons that represent functions or tasks into a flow of functions. This kind of interface has been in use for decades, and one that I was first introduce to in the software package Khoros / Cantata in the early 90s (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.9854&rep=rep1&type=pdf). Clementine was an early commercial tool using this paradigm (now IBM Modeler), and now most tools, including those that have historically used drop-down “Windows-style” menus, are embracing a workflow interface. And it’s not just commercial tools that are built from the ground up using a workflow-style interface: many open source software like KNIME and RapidMiner embraced this style from their beginnings.
Even though workflow interfaces have won the day, there are several excellent software tools that still use a typical drop-down file menu interface for a variety of reasons: some legacy and some functional. I still use several of them myself.
There are several reasons I like the workflow interface. First, it is self-documenting, much like command-line interfaces. You see exactly what you did in the analysis, at least at a high level. To be fair, some of these nodes have considerable critical customization options set inside the nodes. Second, you can reuse the workflow easily. For example, if you want to run your validation data through the exact same data preparation steps you used in building your models, you merely connect a new data source to the workflow. Third, you can explain what you did to your manager very easily and visually without the manager needing to understand code.
Another way to think of the workflow interface is as a visual programming interface. You string together functional blocks from a list of functions (nodes) made available to you by the software. Command line programming does largely the same thing: you have a set of functions available to you that you string together. For example, you may want to load a csv file, replace missing values with the mean, transform your positively-skewed variables with a log transform, split you data into training and testing subsets, then build a decision tree. Each of these steps can be done with a particular function.
From this perspective, the biggest difference between visual programming and command line programming is that R and Python have a larger set of functional available to you. From an algorithm standpoint, this is primarily a difference in less-used or cutting-edge algorithms that are available in R or Python but not in most commercial. This is one important reason why most visual programming interface tools have added R and Python integration into their software, typically through a node that will run the external code within the workflow itself. The intent isn’t to replace the software, but to enhance it with functions not yet added to the software itself. This is especially the case with leading-edge algorithms that have support in R or Python already because of their ties with the academic community.
Personally, I used to create code regularly for building models, primarily in C and FORTRAN (3rd generation languages) though also in other scripting (4th generation) languages like unix shell programming (sh, csh, ksh, bash), Matlab, Mathematica, and others. But eventually I used commercial software tools because my consulting clients used them, and they contained most of what I needed to do to solve data mining problems. Since they all have limited sets of functions, I would have to sometimes make creative use of the existing functions to accomplish what I needed to do, but it didn’t stop me from being successful with them. And I didn’t have to write and re-write code for each of these clients.
Each of these tools have their own way of performing an analysis. Command line tools also have their own way of performing an analysis. Much of what separates novices and experts in a software tool is not an awareness of the particular functions or building blocks, but an understanding of how best to use the existing building blocks. This is why I recommend analysts learn a tool and learn it well, becoming an expert in the tool so that the tool is used to its fullest potential.
NOTE: as of the posting of this article, the Rexer Analytics 2015 survey is still open. If you haven’t participated in the survey, go to http://www.rexeranalytics.com/Data-Miner-Survey-2015-Intro2.html and use the code 7A9A52 when prompted.
Author Bio:
Dean Abbott is Co-Founder and Chief Data Scientist of Smarter Remarketer, Inc., and President of Abbott Analytics, Inc. in San Diego, California. Mr. Abbott is an internationally recognized data mining and predictive analytics expert with over two decades of experience applying advanced data mining algorithms, data preparation techniques, and data visualization methods to real-world problems, including fraud detection, risk modeling, text mining, personality assessment, response modeling, survey analysis, planned giving, and predictive toxicology.
You must be logged in to post a comment.
Thank you, Dean, for reminding people to participate in the 2015 Data Miner Survey (http://www.rexeranalytics.com/Data-Miner-Survey-2015-Intro2.html). We will keep it open through May. And I completely agree with you — anyone interested in this topic of programming languages for predictive modeling will want to immediately go read Bob Muenchen’s very thorough analyses at r4stats.com (http://r4stats.com/articles/popularity/).
— Karl Rexer (President, Rexer Analytics)
Pingback: What Programming do Predictive Modelers Need to Know? | Learn programming language-Create a new programLearn programming language-Create a new program