We had a "C++ interpreter" called CINT for a long time, which the ROOT data analysis framework was built around. It was, to put it bluntly, a mess: it had inconsistent scoping and syntax with C++, gave worthless debugging messages, and couldn't handle a lot of standard C++ code.
It was also the way that a lot of physicists at CERN ran their analysis code. We needed an interactive language to make graphs and histograms and to fit our data, and when CINT was conceived the only other solutions were proprietary packages like MATLAB. So CERN went with a homegrown solution and wrote a C++ interpreter many years ago.
Flash forward 15 years. "Big data" is all the rage. Python, R, and the huge list of packages built around around them would easily solve the problems CINT was designed for. But the codebase for the larger experiments at CERN is maintained by physics graduate students, a good fraction of whom had no programming experience before grad school. We don't have the time or the resources to rewrite our existing code in scipy, and the older generation doesn't have the experience to supervise such a transition.
Given that so many physicists are still using CINT, the ROOT developers had to make a choice: they could continue to maintain CINT, which would have been nearly impossible with their resources and the evolution of C++, or they could rewrite something that did almost the same thing using more modern tools. They opted for the later.
cint (M. G.) was in maintenance-mode for a long time by then.
ph-sft group was more for python (P. M.), and fnal wanted llvm/c++ (P.C.).
fnal then put down the money for an IC contract (A.N.) at ph-sft for the llvm/c++ based implementation and joined the iso body.
cling is almost orthogonal to the whole ROOT mess (graphics, histogramming, partially the analysis etc.)
Actually there was an early attempt to provide C++ repls back in the early 90's with Lucid Energize C++, after they pivoted from Lisp Machines and applied their knowledge to C++.
Also the majority of CERN code is written in a mix of Fortran and C++, and not all teams like to use Python. So they rather use something that provides interactivity to research their algorithms and speed at the same time.
Now imagine if that was the standard way everyone worked by now.
git clone https://root.cern.ch/git/root.git src
Username for 'https://root.cern.ch':
Password for 'https://root.cern.ch':
fatal: Authentication failed for 'https://root.cern.ch/git/root.git/'
I've only used interpreters in MATLAB/R where you have to write one-liners to massage data into the format you need - which seems pretty orthogonal to the way you work in C++
And now with the ipython notebook (jupyter) I use the shell in a third way, to repeatably explore and demonstrate larger, less isolated things that are still sort of one-offs.
That said, I think the fact that there is a significant handful of C++ compiler/implementations in use, and some latitude in behavior for each, means that a C++ user is very much a user of the compiler as much as the language. Play but verify, I guess.
But CERN developed a huge amount of CINT code anyway, and all of CERNs legacy sort-of C++ code that ran on CINT became a maintenance nightmare. Cling is a huge upgrade in the sense that it supports all this legacy code with a _lot_ less overhead than before.
(Saber-C, the Saber company has become Centerline, and the software itself has been renamed to CodeCenter.
saber, xsaber, and sabertool have become codecenter, xcodecenter, and codetool. DEC offered Saber-C on ULTRIX. It never appeared to do very well in the marketplace, which is some kind of tragedy. It was, and is, a terrific piece of software. The fact that a product as useful as Saber-C could fail to do well in the market is an indicator of the impoverishment of software "engineering" practices industry-wide. Anyway, it ended up being ObjectCenter from Integrated Computer Solutions doing C++ and having an IDE with class browsing, with xobjectcenter)
Or C++ Builder or C Set++ for OS/2 (might have the name wrong).
If it wasn't for tool vendors having switched their focus from C++ to Java and .NET, until LLVM and clang got created showing everyone what was wrong with their approaches, C++ IDEs might have been much more advanced already, in spite of technical issues with language.