HN Theater @HNTheaterMonth

The major issue with C++, is what also helped the language gain market adoption, copy-paste compatibility with most of C89 code.

So security conscious C++ developers tend to use enum class, string, vector and array classes, RAII, iostreams, wrapping data access in classes with invariants,...

Developers with more C oriented mindset, tend to just code away like "C with C++ compiler" programming style.

Hence the need being discussing since the last three CppCon, to stop using C style programming in modern C++.

CppCon 2015: Kate Gregory “Stop Teaching C" - https://www.youtube.com/watch?v=YnWhqhNdYyk

CppCon 2015: Bjarne Stroustrup “Writing Good C++14” - https://www.youtube.com/watch?v=1OEu9C51K2A

CppCon 2017: Bjarne Stroustrup “Learning and Teaching Modern C++” - https://www.youtube.com/watch?v=fX2W3nNjJIo&t=2s

Of course, preventing copy-paste compatibility with C, already solves many of those issues from the get go.

⬐ jacquesm

> Developers with more C oriented mindset, tend to just code away like "C with C++ compiler" programming style.

The way I've seen it described is 'C with more convenient comments'.

⬐ makapuf

You mean C99 ? What I really miss from C , with some of the things of this article, is constexpr, compile time checked enums, ...

Stroustrup has proposed a way to add safety to C++. It's called "C++ Core Guidelines", and "GSL".

https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-...

https://github.com/Microsoft/GSL

I watched his talk -- wondering if anyone is using it. https://www.youtube.com/watch?v=1OEu9C51K2A

Using GSL gives adds some safety to pointers and memory allocation -- while providing the bare-metal performance that C is known for. (It still feels very low-level.)

i remember that Bjarne Stroustrup held a talk in cppcon15 where he talked a lot about the GSL library [1] - it would add type annotations that can be checked by a tool, so as to check for potential memory problems (to me that sounds like a poor man's borrow checker).

One year later: i see the template library [1] but i don't see the analysis tool. Does anybody know what happened with this initiative?

[1] https://www.youtube.com/watch?v=1OEu9C51K2A

[2] https://github.com/Microsoft/GSL

⬐ pjmlp

The tools are called clang tidy and Visual Studio 2015 Update 3.

Other vendors might eventually add support as well.

It's hardly modern C++ what you will see in this talk. Mike Acton even said that they only use C++ because it's game industry standard but he would prefer C. If you want to start with modern c++ watch this: CppCon 2015: Bjarne Stroustrup “Writing Good C++14”

https://www.youtube.com/watch?v=1OEu9C51K2A

Background upfront: I'm the guy behind the C++ interpreter and ROOT's new interfaces. I'm the co-author of the only surviving C++ reflection proposal and the author of the std::variant proposal. I have contributed to the C++ Core Guidelines (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://youtu.be/1OEu9C51K2A).

* HEP stores about 0.5 exabytes of data in ROOT format, that's almost exclusively serialized objects that do not know anything about TObject.

* XRootD is not really specific for ROOT files. A better example would maybe be our JavaScript de-serialization library, https://root.cern.ch/js/

* No way will the python binding be dropped. I wonder where you got that rumor from. About one third of our users is using it.

* HEP is limited by CPU resources, which is part of the reason why HEP decided to use a close-to-bare-metal language for the number crunching part.

* We just made the use of python and R multivariate analysis tools with ROOT data more straightforward.

* We have people from genomics etc coming to ask for help, because they cannot find a system that scales as well as ROOT does.

And then we have a different perception of the direction out there. I see that Hadoop was nice but slow, Spark is nice but slow, so now things are moving to C++, see e.g. ScyllaDB. There is no reason for us to move away from it, but every reason to make it more usable.

And yes, I agree that this is an issue. But many physicists do not.

⬐ alxprc

Thanks for clarifying. You're right that I was too broad, and it's certainly true that many physicists don't share my opinion (I'm working on that).

Speed is always a concern, but I don't think it dictates that C++ should be the primary ‘user-facing’ interface. Numpy is fast, but it doesn't sacrifice a nice API to achieve it.

Personally, a big difference is that a lot of the Python packages feel fast to use and, most importantly, to write. ROOT can be fast to execute, no question, but I feel like I'm fighting against it (and I'm sorry that's very vague and qualitative).

It would be very interesting to hear more about the genomics use-case, and how they evaluated the other options.

⬐ whyever

I'm using Python for analysis, and I'm running into performance issues constantly.

⬐ pwang

If you want easy scale-out and scale-up with Python, check out the (relatively) new library Dask: http://dask.readthedocs.org

⬐ konschubert

The thing that bothers me most about root is that some parts of it are basically not maintained at all.

There are serious bugs in RooFit which haven't been fixed in years. Wouter Verkerke has abandoned it (from what I can tell). Lorenzo Moneta is fixing the worst potholes, but it seems is has no authority or no time to tackle the misguiding interface and the broken scaffolding of RooFit.

Maybe ROOT7 will be a chance to take ownership of RooFit again.

⬐ jhbadger

Have there been any success stories in regard to genomics and ROOT? About 10-15 years ago the group I was with then explored ROOT as the alternatives (Perl, early versions of R, etc.) weren't very attractive. We didn't end up going with ROOT ourselves for a variety of reasons, but did anyone else in the field do so?

⬐ batbomb

* ROOT files still have terrible documentation. Rene throws up his arms in protest anytime people say this (I've personally witnessed this)

* Physicists still don't like pyroot interfaces, otherwise rootpy wouldn't exist.

* astropy is proof that you can be performant and user friendly. Julia is proof that you don't even need a C++ library underneath.

* Saying ROOT scales well is weird; It is true that ROOT and the ROOT IO/ROOT files are efficient, but it needs but additional services have helped it scale (dCache, XRootD, batch farm/grid/DIRAC, etc...)

* Not sure what the ScyllaDB tangent has to do with anything. There are scalable open source RDBMS options out there too like CitusDB, Greenplum which support UDFs. Hadoop and Spark with HDFS are still great for certain applications, and as general data analysis tools are great, but it's tricky to really get them to perform well without HDFS and the grid model of computing doesn't lend itself well to that paradigm.

* I've heard the C++ interpreter is much better with Cling (if that's you, I applaud your effort!) CINT was a gun that fired in both directions for every grad student I ever had to help.

* XRootD has little to do with ROOT anymore other than it also implements the original root protocol.

* ROOT is not modular. It is both an application and a collection of libraries and somewhat of a VM. That does make some things convenient, but it also makes some things extremely hard.

There are many reasons to move away from ROOT, and the astrophysics community is a prime example of that!

You should watch those cppcon again, because Stroustrup and Herb are saying there many times that smart pointers are NOT should be use instead of raw pointers. Use smart pointers where It's about ownership. You should watch this video:

https://www.youtube.com/watch?v=1OEu9C51K2A

There is this cppcon presentation by Stroustrup where he is talking about the GSL annotations https://m.youtube.com/watch?v=1OEu9C51K2A but too bad that it all depends on this unreleased big black box proprietary code analysis tool.

⬐ MichaelMoser123

The problem is that you probably can't trust the validator results blindly. You will end up with at least some false reports.

There are some great talks by Neil MacIntosh about the kinds of static analysis they are building into the tool.

CppCon 2015: Neil MacIntosh “Static Analysis and C++: More Than Lint" https://www.youtube.com/watch?v=rKlHvAw1z50

CppCon 2015: Neil MacIntosh “Evolving array_view and string_view for safe C++ code"https://www.youtube.com/watch?v=C4Z3c4Sv52U

For something of this magnitude I wouldn't consider the project late until mid summer.

Stroustrup's keynote at CppCon is a great overview of the semantics they want to support and the errors that the tooling with will prevent. https://www.youtube.com/watch?v=1OEu9C51K2A

⬐ steveklabnik

I had watched Stroustrup's talk, but not Neil's. Thanks!