A list of systems, applications, and libraries that are written in C++

http://en.wikipedia.org/wiki/Fragile_binary_interface_proble...

I wonder how modern C++ frameworks are handling this?

And everyone knew the huge amount of software in C++. Why the list?

Like anything boost spirit has a leaning curve. You could just as easily say no one should use emacs because it is hard to learn. In fact I personally don't use emacs because I found it too hard to get going with, but I don't from there extrapolate that no one else should use it.

The compile time and binary size problems of boost spirit can be addressed by factoring your grammar into smaller subgrammars in separate compilation units. The subgrammars can still be combined the same as rules can be.

The obscure error messages can be improved by using typeful programming so that you get an error like "no conversion from MyRuleADatatype to MyRuleBDatatype".

Yes these things are still problematic, but how do we get from "X is hard" to "no one should use X"? See the Clojure author's talk on Simple vs Easy: he lambasts programmer culture for being obsessed with 'easy' to the detriment of creating useful stuff. He asks, what if the Foo Fighters said guitars are hard to play, let's play kazoos because they are easy. Would you listen to the Kazoo Fighters, he asks.

You can ignore the more restrictive rules (for embedded systems) if that's your case.

Because type 'fixing' (that is, knowing what you need) happens at compile type, for example, duck typing ("even with" dynamic_cast - yes, dynamic_cast works at run-time, but you're limited in what kind of objects - by your inheritance hierarchy - can be present at the time you're doing the dynamic_cast)

You end up having to specify the type, you don't have a 'Generic' type. And you may have to deal with dynamic_cast

And read again, I'm not against STL, they 'get' templates.

Edit: confusing explanation

Firefox/Chrome: C++ looks like a good choice, still, there's a lot of JS behind them as well if I'm not mistaken. Now, Go may be a good choice

LLVM has interesting requirements, it needs to be both fast and needs a lot of 'flexibility'.

I would probably try making the next LLVM version in PyPy (which uses LLVM itself), so it maybe bootstrap itself using CPython first, hence bringing us one step closer to Skynet.

But in general Go/C#/PyPy may be steps in the right direction (Java is too afraid of new things being added to C# like anonymous functions, so it's behind)

I once wrote a large part of a CSS+HTML renderer in OCaml (think: the very core of something like Firefox), and the ability to match over data structures and use trees naturally was a huge advantage.

ML was devised as a language to write compilers in, so LLVM is covered.

For an operating system you really want a lot of different languages because it's a huge undertaking that covers many domains. MirageOS is an OS written in OCaml, so that's a proof that it's possible at least.

Why this over C++? Well, first of all, basically anything is better is C++ at this point, but as for why Lisp in particular, there are a few reasons. First, I won't deny my own biases -- I know Lisp, I use it in my work, and I know that the tools to do the things I mentioned above already exist (perhaps an ML fan can answer whether or not such things are available in SML or OCaml). Second, Lisp is never really "out of date," in the sense that you do not need to rewrite your compiler to introduce a new language feature (consider what was required to add lexical closures to C++, and compare to something like CLOS, which can be implemented in macros for Lisps that do not have object oriented constructs). Finally, there is the expressive power of Lisp; an experienced Lisp programmer will run laps around an experienced C++ programmer, simply because it is easier to describe a complicated program in Lisp than in C++ (this argument also applies to ML, Haskell, Python, and dozens of other languages; again, I will not deny a personal bias towards Lisp).

There is the saying that any sufficiently large program contains a buggy and ill-specified version of Common Lisp... I would rephrase that as any sufficiently large program needing to contain its own extension language and programming language. JavaScript is filling that role for the browser, and I expect there to be a language in the future that does it better.

There won't be anything that replaces C (or C++). Go can't do it. But there will be something that works better with C and C++ for big performance-intensive applications. Lua is close. The reason I would prefer C is that C++ has a very hostile interface for another programming language to interface with.

I wish Python were there, but it's C API isn't really up to the task, especially with regard to concurrency (which e.g. Firefox and Chrome have a lot of!).

At this point, C++ should be placed in the same category as COBOL: it is a language you learn because you need to maintain some old code that nobody has time to rewrite or replace.

Wait until you try Aperture, performance-wise Lightroom is heaven. I moved to Lightroom for this very reason. Adobe also supports new Camera's RAW formats earlier than Apple.

I never really peeked into the application bundle of Lightroom, but at least some of the plugins that I used were written in Lua.

http://www.alejandrosegovia.net/2011/09/08/herb-sutters-why-...

That Microsoft would recommend JavaScript or C++ is unsurprising, considering how much business those languages have generated for them and how many programmers who support the Windows ecosystem are only comfortable in one of those two languages.