
Why C++ Sails When the Vasa Sank [pdf] - dirtyaura
http://files.meetup.com/1455470/Why%20C%2B%2B%20Sails%20When%20the%20Vasa%20Sank.pdf
======
AnimalMuppet
To me, the key line was "Most of the complexity of C++ is hidden from most of
the users most of the time."

The complexity is there. Trying to understand the whole language at a
language-lawyer level is mind-boggling. Trying to write libraries that make
proper use of the goodies is very hard.

But using C++ isn't so bad, as long as you don't try to use every aspect of
it. Just use the parts you need to be able to do what you're really trying to
do. You don't have to pay for what you don't use. That's good enough for a
huge number of programmers in a wide variety of contexts.

There's a lot of haters that can point out a huge number of flaws. But here's
the thing: Most of them, I never run into. I don't care if the move syntax is
confusing; I don't use it. Maybe I never will. If I have to, _then_ I'll care
about how good or bad the syntax is. In the meantime, the parts I actually use
let me get my work done better than any alternatives.

~~~
rayiner
> The complexity is there. Trying to understand the whole language at a
> language-lawyer level is mind-boggling.

It makes me uncomfortable not to have that level of understanding for a
language that's so low-level and doesn't have the "Do What I Mean" bent of say
Python. I'm "meh" on C++ going forward. I invested a lot of time into my copy
of "The C++ Programming Language" (3d Ed.), for C++ 98, but I can't motivate
myself to get the new edition and learn in the ins-and-outs of C++ 11. It
doesn't seem worth it to me. I'm really hoping Rust catches on. It's a complex
language in the same vein as C++, but the bang-for-buck in terms of
expressiveness relative to complexity is better, I think.

~~~
tptacek
I'm a former C++ programmer (and a current C programmer) and my go-to language
is currently Golang; here's why I'd virtually always choose Golang before C++:

* Streamlined language with carefully-chosen syntax and keywords (there aren't 10 different meanings for "static", for instance); entire concepts have been eliminated to no apparent ill effect in building real systems. Fewer cycles allocated to the language, more cycles allocated to problem domain.

* The 95% case for associative and sequential containers is built into the language, with (for me) enormous benefits to programming efficiency.

* A streamlined and carefully orthogonalized standard library optimized for systems programming. Golang has the best-designed standard library I've ever used.

* A ruthlessly pragmatic packaging and modularity system; unlike C++, packaging is not left up to the build system.

* Build-world compilation times measured in 100s of milliseconds rather than 10s of minutes.

If I was writing, say, a generic trie library that I was hoping to get
hundreds of different programmers to use, C++ would be a tempting target
because of generics. But it turns out, most of the time I build projects like
that, I'm really just wanking. Another benefit of Golang is that it's so
stripped down and pragmatic that it subtly discourages wanking.

A lot of people would add Golang's concurrency model (share by communicating
instead of communicating by sharing) and lightweight threads to this list. I
like Golang concurrency too but my sense of it is that among languages
designed from the jump for concurrency, this isn't that much of a unique
benefit.

~~~
lttlrck
Is go really suitable for system programming as defined in TFA?

~~~
tiedemann
Go can link to assembler and C routines so yes, I would think Go could be a
good language for mid/top-level stuff.

------
Tomte
When in Stockholm, go visit the Vasa museum. It's absolutely breathtaking.

Make sure to get a guided tour. You can read all the stuff on the displays and
in books, but you probably won't. So you'd lose all those nice stories about
how the German ambassador protested the ship, because the figurines on the
front symbolized the Roman emperors, with the Swedish king at the very front.
Preposterous! The emperor of the Holy Roman Empire of the _German_ Nation is
the rightful successor to the Roman emperors, after all!

Pay attention to the fact that the Swedes weren't as stupid as people tend to
assume. "Oh, they couldn't even build a ship that's floating!".

Yeah well, it was a design no-one had attempted before (bigger, three masts,
two rows of cannons), the math to calculate the behaviour wasn't available,
yet. And best of all -- contemporary analysis shows that they almost made it.
Had the ship been just a little bit wider (I don't know, something like 20
centimeters or so?), it would have been fine.

Be amazed how the Swedes never just found a scapegoat to punish for the loss
of their flagship.

Or just admire the architecture of the museum.

Whenever I'm in Stockholm I go there. It's inevitably a high point of my
visits.

~~~
bjourne
Several people working on the design of the ship knew it never would sail. But
since voicing their criticism about the king's unrealistic spec carried the
risk of getting beheaded they kept their mouths mostly shut. The master
shipbuilder who was in charge of the project fled back to Holland when Vasa
sank. It was a classic case of hoping someone else would get the blame when
the shit hits the fan.

------
4bpp
The way people like to complain about the bloat and arbitrariness of C++, but
then still quietly wind up using it, reminds me a lot of the common complaints
about the arbitrary pronunciation and other quirks of the English language.
There is, of course, the trivial commonality that "everyone understands it and
a lot of useful things have already been written in it", but at least part of
the reason why languages like Esperanto or even Lojban don't catch on is that
while many like to extol the virtues of a (natural or machine) language being
simple and unambiguous on paper, in practice, more often than not people
arrive at a point where they perceive the very un-Pythonic benefit of being
able to express the same thing in more than one way (and, conversely, being
able to convey more than what the words/code say at face value).

The natural language example of course being metaphor and allusion, I am
thinking of practices such as indenting glVertex calls inside a glBegin/glEnd
block, or overloading () on an object to convey the idea that "you should
think of this as something like a function" when it is really not on a
technical level.

~~~
rbehrends
> The way people like to complain about the bloat and arbitrariness of C++,
> but then still quietly wind up using it

Most such people are probably in the same position that I am in, and this is
that they're using C++ primarily because they're involved in projects with a
C++ legacy codebase. Language choice really isn't something that's up to
individual developers.

But for personal projects, I've pretty much abandoned C++, other than when I
need something to bootstrap on platforms that I can't make a whole lot of
assumptions on, or when I have to operate close to the metal and C for some
reason or another doesn't fit the bill.

The thing is that I don't really have a lot of beef with the language features
of C++ (the way they're used in some libraries is a different issue). The
features it has are generally there for a reason, and have good rationales.
And C++ does pretty well in its chosen domain (system programming). It's not
perfect (what programming language is?), but hardly terminally flawed, either.

But C++ simply doesn't meet my needs. It has a very strong bias for optimizing
CPU cycles, even at the cost of developer cycles, but I'm far more likely to
be short on the latter than the former. Those extra few percent of speed that
I might gain (or might not -- some C++ features are not all that efficient,
after all) are rarely worth adding even a few hours of development time.

------
cacainmycafe
I like C++ because I only pay for what I use in the language. Very little
overhead or additional baggage to slow or weigh things down, unless, I elect
to include the extra luggage.

The recent updates - C++11, C++14 and the drafts for C++17 are also very
welcome.

When you need performant, deterministic, portable and testable code, you go
for C++.

~~~
heinrich5991
The new Rust language by Mozilla makes similar promises,

* only pay for what you use

* memory safety

* testability

* portability

(They even got a standard testing module.)

EDIT: How do you make lists with Hacker News markup?

~~~
freyrs3
Conceptually they are similar, though it's always important to note that C++
has several man-centuries worth of compiler work. Rust may become stable and
efficient enough to replace some existing C++, but at the moment it's most
certainly not as mature as the existing C++ ecosystem.

~~~
pornel
Rust uses LLVM, so it benefits from the same optimizer as clang. The front-end
is less mature of course, but also Rust is less complex, so may not need man-
centuries of work to be parsed properly ;)

Currently Rust doesn't outperform C++ partly because LLVM is optimized for the
C subset (can't take advantage of extra aliasing/immutability information Rust
has), but given that Apple is now betting on (quite similar) Swift I expect
LLVM to rapidly improve in this area.

~~~
gsnedders
Also remember most of the work on Rust at the moment is focused on stabilizing
the language — performance is only really required to be acceptable for now,
provided it is possible to improve.

~~~
steveklabnik
Yes, there are several places where, for example, we generate sub-optimal LLVM
IR, but time is better spent getting the interfaces and language spec correct
for 1.0 than squeezing out performance.

I should mention that that's different than 'who cares about performance,
let's toss this in.' Performance aspects are absolutely taken into account
when changing the language. But that's different than the implementation
itself.

------
ingve
The video:

[http://tech.yandex.ru/events/cpp-party/june-
msk/talks/1954/](http://tech.yandex.ru/events/cpp-party/june-msk/talks/1954/)

~~~
angersock
I've never seen footage of Meyers before...He kind of reminds me of the Tall
Man from the Phantasm movies.

I guess C++ will do that to you. :)

~~~
72deluxe
I always thing his prog-rock 70s haircut makes him look like one of Robin
Hood's merry men or a medieval archer.

Not that this is a bad thing.

------
alexvr
I think its "excessive" features make it an appealing language so long as I'm
not dealing with not-so-well-written and/or expertly "clever" code.

I find straightforward, well-written C++ more comprehensible than Java and
even Python (only due to Python's dynamic typing).

Of course, the definition behind straightforward, well-written C++ is very
subjective.

------
thrownaway2424

      auto y = std::move(x);
    

Is this good code? How do you review it? What's the type of y? Usually I would
ask for at least one type statement per line. For example this seems ok to me,
because the type is on the left.

    
    
      auto* x = new Foo();
    

But this doesn't seem ok:

    
    
      auto y = std::move(x);

~~~
RogerL
Do you allow this to pass code review (ignoring the bad name 'foo')?

    
    
      foo (A*x);
    

'A * x' creates a temporary with no documented type, but the conceit here is
that we don't care. They could be ints, floats, matrices - any data type that
implements '*'. By and large that is fine.

Here you are just moving x to y. What is the type of y? the same type as x,
which supposedly didn't cause you heartache throughout the rest of the
function.

Stroustrup gave an interesting talk this year about how, everytime he
introduced a new feature, people complained that it was not clear and asked
for very verbose syntax. Instead of foo<T>, we get template<typename T>
foo<T>(T, well, you get the idea. Now everyone is familar with templates and
loath the verboseness.

Back to auto, it allows for 'generic' programming. Do you object to templated
functions?

    
    
      template<class T>
      T add (T a, T b)
      {
         return a + b;
      }
    
    

That seems really clear to me, as is the auto version:

    
    
       auto add (auto a, auto b)
       {
          return a + b;
       }
    

If that is clear, why is

    
    
       auto x = a + b;
    

unclear? I can certainly come up with counterexamples where it isn't clear,
but by and large I love auto, and use it all the time. (counterexample: we
care about the type of x because we need to cast to a 16-bit int because it is
going to be use to communicate with hardware).

~~~
yongjik
Problem arises when we find "y" deep in a function, searches for its
definition, and encounters "auto y = std::move(x);". Now we have to know the
type of x, and if x is defined similarly, up the chain. Not fun.

foo(A * x) doesn't pose similar problem. On the other hand, if I write

    
    
        auto bar = foo(A*x);
    

Then we can have the same problem (esp. if foo is a templated function).

~~~
RogerL
To be honest, I just hover my mouse over 'bar' to get the type, and I name
'bar' something more meaningful than bar. "ball_covariance",
"movie_recommendations", or whatever that matrix multiplication is computing
for me.

I wrung my hands when I started using 'auto' but none of the worries came to
pass.

But yes, if the code is unreadable without a type, add a type. No biggie, and
no one is suggesting inflexible application of rules (always use 'auto' if it
is possible). The same way when I might call

    
    
       foo(boo(x));
    

and it is not clear, I'll explicitly name the output of boo in a temporary
variable:

    
    
       auto robot_velocity   = boo(x);
       auto robot_covariance = foo(robot_velocity);
    

And if that ain't enough, then sure, do this:

    
    
       robot::vector<float> robot_velocity         = boo(x);
       robot::matrix<float,float> robot_covariance = foo(robot_velocity);
    

I have to say, I find the last the most unreadable. I almost never care deeply
about the type, and care deeply about the meaning.

Interestingly, no one worries about typedef. typedefs wrapped around intricate
collections (map of lists of dictionary of arrays) can effectively obscure
what the underlying types are just as much as auto. But again, mouse hover,
CTRL+I, or whatever your IDE supplies pretty much makes that a non-issue as
well.

edit: the problem you are describing is due to too big a function, not 'auto'.

------
eatitraw
Scott did an amazing talk in Moscow two weeks ago. The slides look the same.
Here is the link to the video:

[http://tech.yandex.ru/events/cpp-party/june-
msk/talks/1954/](http://tech.yandex.ru/events/cpp-party/june-msk/talks/1954/)

------
vasilipupkin
I've been using C++ for many years, and, sure, it has a ton of various
features, not all of which I use all of the time. But, being comfortable with
it, I don't find it any harder to program in than Java or Python. I am not
sure if it's fair to say that the learning curve is higher to get to that
point. But then again, if you do silly things in Java, won't your code be slow
as well?

------
vilya
The line that stood out to me was the quote from Stepanov, about C++ being the
only language in which it was possible to implement the STL. To most people,
that would have been a hint that perhaps the design of the STL was flawed...

I think the STL may have been the worst thing to have happened to C++. It
could have been so much nicer if something like Qt (the core part) was adopted
instead.

~~~
72deluxe
Which bit about Qt were you hoping was part of the STL? I think the design
goals of the STL was to make it portable, something Qt is not, despite being
multi-platform. We mustn't forget that C++ is used on very low level devices.

If Qt is anything like wxWidgets, wxWidgets reuses the STL for its container
types, basically providing a thin wrapper over the STL (or it can do with a
build switch).

I myself find the STL very useful, so I am genuinely interested in which bits
of the STL you wish were more Qt-like? Do you mean the GUI bits of it or
something?

~~~
vilya
How do you define portable? If you mean the same code compiling and running
out-of-the-box on Windows, Mac and Linux then actually my experience with Qt
has been very positive in that regard. Those are the only platforms I develop
for right now, so I can't ocmment about portability to e.g. iOS or Android
(although I believe Qt ports are available for them).

Qt doesn't reuse the STL container types, it provides its own - which I find
much more pleasant to work with than their STL counterparts. The STL puts a
lot of effort into providing types of flexibility that are irrelevant or
useless to me (e.g. allocators) and doesn't provide lots of simple things that
I need every day (e.g. an indexOf method for std::vector, a contains method
for std::set, or a toUpper/toLower method for std::string).

~~~
72deluxe
Ah I see what you mean. I should dig out Qt again really - I haven't used it
for years. I have managed to make do with wxWidgets.

Regarding iOS and Android, the attempts at getting C++ on them (particularly
Android) are brave but I think for normal apps (not OpenGL or games),
developers are probably better using Java. Like you, I too am writing for the
Big 3 normal desktop OSes, with sporadic Android development and iOS
tinkerings, necessitating learning new languages.

------
lutorm
Why does the title slide show a ship flying a US flag? He obviously has
correct pictures, because they are in the later slides...

~~~
wmkn
Because it is a pretty picture and the ship with the US flag represents the
sailing part in the title of the presentation.

~~~
lutorm
What, like C++ comes from the US?

~~~
mikeash
It was created here, although it has long since transcended its origins.

------
jokoon
there are still things I wish would be possible for c++. I'm not a language
expert, but I still wish for those things.

* non templated tuples instead of struct: for example, 2 struct types are the same if the data types they hold is the same. Not sure if it's possible for statically typed language.

* tighter STL container integration with the core language syntax

* some way to do modules

* some new thing to make compiling much faster, so to avoid relying on precompiled headers. go and rust are so much faster for this, C++ is not. I still wonder if there could be some gcc or clang extension for this, it would be really appreciated. C++ is awesone to work with, but language implementations suffers from those little details.

~~~
loup-vaillant
ML and Haskell are statically typed, and have tuples as you describe them. For
instance, the tuple

    
    
      (42, "foo", fun x -> x+3)
    

has type

    
    
      int * string * (int -> int)
    

in ML. It would probably be a serious extension to C++'s type system, though,
and for limited benefit: you're asking for yet another way to do Cartesian
product. Structs already do that. What's sorely lacking is sum types:

    
    
      type 'a option = Some of 'a
                     | None
    
      type 'a list = Cons of 'a * 'a list
                   | Empty
    
    

\---

Integrating the STL at a syntax level gives a special status to the standard
library, preventing users from writing effective replacements or analogies.
Also, C++ has precious little orthogonality left, let's not destroy it.

\---

What kind of modules are you talking about? C++ has compilation units,
classes, and namespaces. What capability do you want that they don't already
provide?

\---

Good luck on the fast compilation front. That one will likely require
_removing_ things from the language, or making some major compatibility-
breaking changes in the syntax (to make it easier and faster to parse), and
possibly a rework of the template system. No. Way.

~~~
AnimalMuppet
If I understand correctly, Go is the "removing things from the language"
approach to fixing the fast compilation issue.

~~~
robmccoll
Yes. Namely templating.

------
santaclaus
Why can't we simply have C + RAII + generics? That would be a baller language.

~~~
10098
throw in first-order functions and lambdas as well, replace generics with
templates the way they are now, and I'm all for that!

------
detrino
I really enjoyed this talk. The Q&A session was great as well, Scott is an
entertaining story teller.

------
Moral_
Why do people insist on linking to slideshare?
[http://files.meetup.com/1455470/Why%20C%2B%2B%20Sails%20When...](http://files.meetup.com/1455470/Why%20C%2B%2B%20Sails%20When%20the%20Vasa%20Sank.pdf)

~~~
dang
Thanks. We changed to that from [http://www.slideshare.net/yandex/why-c-sails-
when-the-vasa-s...](http://www.slideshare.net/yandex/why-c-sails-when-the-
vasa-sank).

