[ddavis]

Very cool! I watched the SciPy talk on xtensor (same developers as xeus) and the project looked pretty awesome. Many people in my field used CINT for a long time and cling is so much better. It's nice to see it used outside of particle physics.

One thing I disagree with is the idea that the lack of a good interactive environment for C++ makes it difficult to teach. C++ is a compiled language, so learning how to compile a C++ library or program is _part_ of C++. I feel like C++ beginners should go interactive _after_ learning how to compile a project. I write that with first hand experience; my first programming experience was with writing interpreted C++ in CINT and I feel like it hindered my ability to eventually understand what a real C++ program was.

[jmabille]

I agree that the compilation process is part of the C++, however (and that's from my teacher's experience), teaching it to beginners as a first lesson may be complicated (and you have to teach it early so they can build their first program). Besides this is not rewarding when your students are familiar with other languages like python where they can write some code and have immediate results without any additional step.

So having a good interactive environment is really useful for the first lessons, then you can teach the compilation chaintool and switch to a real environment.

[xfer]

Compiling a project with right incantation of flags is not rocket science but it is time consuming that a build system should be better equipped to do.

Interactive development has immense benefits in exploring apis for experts and learning the language for beginners. And C++ is not well-known for its compile-times.

[dguest]

Someone else commented on the semantic difference between the narrow definition of C++ as a specification and the looser "C++" as a part of the full stack.

With regard to the full stack, I tend to agree with you, at least in the academic environment. Organizations that don't have a lot of software engineers will shoot themselves in the foot if they focus on the C++ language rather than the infrastructure around it. An interactive notebook is great to teach someone to add a few lines of code here or there, or to run quick tests, but what we're lacking is people who understand how to plug their jupyter notebook into the production line.

[pjmlp]

C++ on environments like C++ Builder is relatively easy.

The issue is developers having open mind to such environments, luckily it seems to be changing with QtCreator, CLion, VC++, specially thanks to clang being implemented as a library.

[jcelerier]

> so learning how to compile a C++ library or program is _part_ of C++.

I entirely disagree. This is only for historical reasons, the language itself does not care at all about the compilation model. This mindset is what is keeping C++ back, both for the industry AND in students' minds.

> I feel like it hindered my ability to eventually understand what a real C++ program was.

The moment you have a .o file it's not a C++ program anymore, but a platform-specific object file. You aren't learning C++ but windows / mac / linux's native binary production toolchain.

[ddavis]

> The moment you have a .o file it's not a C++ program anymore, but a platform-specific object file. You aren't learning C++ but windows / mac / linux's native binary production toolchain.

Then that is at least part of the learning curve of seriously using C++ so I think as of today it's (potentially) dangerous to start with only interpreted code and wait to be introduced to compiling, build tools, etc. They should be taught together. I also think it's not the greatest environment - and I hope it changes, perhaps projects like this will help!

[AstralStorm]

Indeed, the language does not care which means you should. Object file is not even a compilation unit at times.

You get to build the object file, shared objects, dlls what have you. Then use the linker to link it to turn it into an executable.

Some modern languages specify the runtime very deep. For example Python or Java - so much that it is hard to separate language from runtime or standard library.