- I have lots to get through,
so we're going to go kind of fast.
I work at Christie.
I do projection mapping.
I turn things like that
into things like that
with multiple projectors for
crazy things like simulators
and theaters.
That's actually a tiny theater.
That's a giant theater.
Whatever, buildings.
A lot of buildings.
That's a great car.
That's also a great car.
It's the same car.
There's the car.
We're projecting color on onto car.
The car is whatever color
you would like it to be,
and that's how that works.
So that's what I do and I'm
not gonna talk about that.
That's just that's what I work on.
That would be an interesting talk.
Okay, Postmodern C++.
I have a lot to get through
and I gave this talk before,
but I needed to shorten it,
to remove some stuff, simplify it,
and then I had an idea, an awful idea,
a wonderful awful idea.
So let's see how it goes.
Overview.
We'll have some slides.
I'll be your guide.
On the slides there will be tweets.
Tweets and tweets on every beat.
There will be graphs.
Almost half the slides are graphs.
That one is a strange laugh.
Some of my talks are low, lock free atomic
which some might find quite abomic.
So talks are high ideas
grand, like this one
like we have here at hand.
Actually this talk is the yellow one
and it's not just high
level, but it's about
three in front of, you know
in a different dimension
than all my other talks.
(man mumbling)
Yes.
(man mumbling)
Testing.
(man mumbling)
Do I just talk louder?
- Yeah talk louder.
- Yeah talk louder.
- [Man] I think you have to
move your mic up a little bit.
- Man, did you miss my good poetry?
All right, that still sucks.
Hello, testing.
- [Man] Your microphone is fine.
(man mumbling)
- Okay, I'm just going to talk louder.
So I was summoned and now am on Twitter.
However, not lock free is glitter.
We had a discussion Modern C++.
With that what is up?
Where did it come from?
Meyers, Alexandrescu?
No, Stroustrup.
So 1999.
So Modern C++ is old and if
you allow me to be so bold,
Post-modern C++ is where it's at.
So let's see what's up with that.
(laughing)
So shall we begin?
Let's dive right in.
The meaning of a container
is the differance it has
with the containers that it is not.
At this point I need to explain
a guy named Derrida
and what he was sayin'.
He came with this word differance.
Maybe you can tell from
a glance it's a mix of
difference and deference.
It's word about words, a meta word,
on that you may never have heard.
I'll try to explain, I'll give it a shot.
A sentence is words,
some used and some not.
Those not used may still
add to the thought.
A house could be a
mansion, a hovel, a nest.
Which ever word you choose is
just more right than the rest.
The others being wrong
defined that which is right.
Its meaning in fact is
found in that light.
That's differance.
Is that okay?
If I may,
here's an example.
I hope that it's ample.
The prime minister of Ireland Edna Kenny
resigned and Jonathan questioned
how UK's tweet was designed.
Why not stable?
Were they not able to give him that label.
So the words not used can still add to
the thought hidden
beneath the words you see.
(man mumbling)
All right, thank you.
Johnathan's here.
Another example.
What is the meaning of foo?
A function, a variable,
an exception you threw?
This is une instance of
the ultimate diffarence.
The meaning isn't here.
It's deferred to elsewhere.
You can't tell differance
was French mix of words.
So foo is untext defined only by context.
So ladies and gents does
my tweet now make sense?
Vector is not list.
That is the gist.
All right, big enough like that.
Each container has its
traits that define the place
where they are great.
Particularly vector you
don't need a lecture,
just use vector.
Never use list.
So we can turn this into a guideline.
When choosing a container
remember vector is best.
Leave a comment to explain
if you choose from the rest.
(applause)
Just, just wait.
So this rule of adding
a comment when you don't
use an expected pattern
is a sample of something
that's subtle.
If you're in the middle
of a muddled puzzle
that has you all fuzzled
because a habitual pattern
in a particular matter
is not feasible, possible or probable.
You apply the habitual pattern,
muddle puzzle defuzzler pattern,
(audience laughs)
i.e. you leave a comment.
So yes, that is also a
pattern applied to pattern.
So it's a meta pattern, a
habitual pattern muddled
puzzler defuzzler meta pattern pattern.
(audience laughs)
Which being a pattern
can be applied to itself.
Making it a habitual pattern
muddled puzzler defuzzler
auto meta pattern pattern,
(man mumbling)
which means if you don't
use an expected pattern and
you don't leave a comment
saying why you didn't
use the expected pattern,
then leave a comment
explaining why you didn't leave
a comment explaining why you didn't
use the expected pattern.
(audience laughs)
(applause)
The truth is outside all fixed patterns.
Okay, deconstruction.
Derrida, one of the
founders of postmodernism
was also the creator of deconstructivism.
Yes, that was a rhymism.
Take some words, now turn them around.
If one word was up replace it with down.
Does that lead to a smile or
does that lead to a frown?
What normally goes here
you place over there.
You can do this with
skill or not even a care.
Now what do you have?
Something moronic, postmodernist like
when it turns out iconic, ironic
and sometimes every once in
a while it's even iconic.
(whistling)
It was quite an interesting
adventure when this was done
to deconstructive architecture.
Same principles.
So have a glance at the following instance
where I've taken an
idea and turn it about.
It become a wonderful idea.
You'll agree I have no doubt.
An API is defined by
the code that calls it,
not by the code that implements it, yes?
(applause)
All right.
First of all, JF always with
the Murph on my tag there
Post-modern C meet Modern C first.
APIs are defined by the
class and functions?
Not so!
Really it's the code that
is used at their junctions.
Is that insightful,
ironic, iconic, catatonic?
(audience laughs)
So, another guideline.
Write examples and tests first, I do say.
Anything else will lead you astray.
Once API usage has spread out ubiquitous,
changing it then would
cause a big ruckitus.
(audience laughs)
How it gets used is the API.
That is something a class can't deny.
I'm waiting for you to
mention client refactoring
or something (mumbling).
Yes, of course I would be a fool to not
mention the client refactoring tool.
(laughing and clapping)
But think of the code the way it was.
But even then surely there
were the insights owed
to all the former calling code.
How you would fix the API.
(exhales)
So this slide took me nearly a day,
but don't want to take it away just yet.
It doesn't really fit my talk though.
(audience laughs)
Pas de bleu sans jaune et sans orange.
There's no blue without yellow or orange.
That's another way of deconstructivism
that the words not used,
the things not used
are still tied together with the you know,
if you think of blue you
should also be thinking orange,
or Van Gogh was insane.
Either one.
There is no blue without yellow or orange.
So continuing, you must
consider the bracket styles
within the context of the
social/economic society
in which they were formed.
This is my attempt to
compile something in the
postmodern style.
This is how people,
postmodernists write things.
But people make such a big racket
of where to place a simple bracket,
but why put developers
in a straight jacket?
How, another dumb tweet.
How we write is as
important as what we write.
I don't mean to be contrite.
Let's get courageous and talk
about this thing that's religious.
What is wrong with the first line?
- [Man] Nothing.
- Tell me your thoughts and I'll
(audience laughs)
explain mine.
Anyone, just for fun?
Plain format.
The first answer is the line is in red.
(audience laughs)
That would be using your head,
but first line is a pain
at a particular time.
(man mumbling)
Breakpoint, that's a great point.
(audience laughs)
The lines aren't disjoints
so where goes the breakpoint?
The problem there is the
breakpoint goes where?
Moving along the second
line might be wrong,
if you also code a lot of Python.
(laughing)
I've never made that mistake.
So for me the argument is
hard to take, but whatever.
Some people find this style too clever.
So on to these last two
from my friend Fabi, Fabio.
This one is major versus
minor, almost one liners.
This one is, the first one is for things
that are inconspicuous and
the second is for things
that need special fokitus.
So yes, in my code I
switch between styles.
I let the circumstances
decide which is worthwhile
and honestly my friend
named Fabio showed me this
and I was like don't do that.
Pick a religion and then he's like no, no,
you switch depending on context.
So fixed formatting is like
trying to run everything.
Sometimes it just gets in
the way of understanding.
Yeah, I will continue.
(all laughing)
Allowing a variety of
formatting can sometimes
be quite liberating and
helpful when communicating.
Just don't take it too far.
This code won an obfuscation Oscar.
It was written by this guy and obviously
it calculates pi.
The sizes of the diameter is
the algorithm's parameter.
Make the circle bigger and you'll
get a more accurate pi figure.
(laughing)
Sure.
Ah, I was told to have graphs.
More graphs.
(audience laughs)
Turn your head, just a tuck.
See the duck.
That's actually from a
hundred year old joke.
Bugs versus lines of code.
(all laughing)
Yeah.
(man mumbling)
The line's not straight.
Yes, that'll be slide 98.
(all laughing)
So for every line there is a bug.
For every bug a hole is dug.
Debuggers, profilers
and sanitizers you love.
More caffeine you have to chug.
Add an if.
That always works.
Deep picture understanding shirked,
but an if is a line so an if is a bug.
Sometimes all we can do is...
(audience moans)
Okay, removing all the aftermath
so we can see the original graph.
As was mentioned
unfortunately this is what
the graph is like.
(laughing)
This is what the graph is like.
As you add more lines,
the bugs will spike.
So sadly the line is not straight.
We'll come back to this, just wait.
First I have more graphs.
A carafe of a width over height.
A height versus distance and shoulder.
This one's very accurate.
This is also a giraffe of surrealism
versus the progression of the talk.
(audience laughs)
What's the chances Bryce
is tweeting this now?
(audience laughs)
Or is he tweeting that I'm
mentioning him in the talk?
(audience laughs)
Now he has to balk of which
part of the talk to tweet.
Warning, we're currently here.
(audience laughs)
Actually maybe even at the
ear, but not at the ossicones.
Anyhow back to a similar tone.
Graphs per slide, we're down at
the beginning of that thing there.
Why is this?
Slides per slide
(audience laughs)
is linear,
unsurprisingly linear,
(audience laughs)
until we get to here.
(audience laughs)
So, obviously that's not correct
because the slide self-reflects.
(audience laughs)
Okay, now I get the, there's another turn,
but I think you get the pattern.
So moving on.
(wild laughter and applause)
Okay, okay, that was wrong.
I think I can fix that.
Give me a moment.
I'll be right back.
Okay, that should do it.
Woops, no.
(laughing)
Okay, okay screw it.
Time for the ultimate fix.
All right.
(laughing)
Let me just restart here.
So where was I?
Ah, I think it was this slide.
Maybe this code explains
what just occurred.
Was this code connected to the projector.
I work for a projector company.
Not that one, but Christie
projector company.
So this class is self-referential.
Maybe it has some potential.
It folds in on itself, but it
doesn't do it quite enough.
Let's add some CRTP to this stuff.
All right.
So instead of this, we have self, bliss.
This is great, this is grand.
Did I mention we have a band.
Of course it's never quite that easy.
C++ rules can make you quite peasy.
This is what you would actually
need to implement this,
but this is grand.
No it is not.
If you saw a code base using self,
you'd be all wat, wot?
WTF, understand this code?
Good luck.
That rhymed.
(audience member laughing)
So, we already have enough paradigms.
This is from my manager at Adobe.
I've since used this quote many times.
Having too many paradigms is not sublime.
I actually worry if meta classes
might fall into this crime.
Too many of them.
Okay, this graph is back.
What we lack is a tact that
gets this problem back on track.
And unless someone like you
cares a whole awful lot,
nothing is going outside get better.
It's not.
This is straight from Dr. Seuss,
but that is not the original page.
This is the page people
on the internet had made.
This is the original page.
It's very much darker,
because our problem is a dark problem.
So how to concentrate on
one section of program
at a time without intrusion
and how to test in isolation?
Click bait.
Post-modern C++ began
with the sub routine.
In a moment you will see what I mean.
I found this amazing
report, only two pages.
Very, very short.
This paper is marvelous.
There's some things here for all of us.
It's not by me.
That's what makes me jealous,
but I'll the author's words tell us.
A self-contained part of a programme.
That is the sub routine's slogan.
An entity of it's own.
I know, your mind is blown.
Here he says something courageous.
Although you don't need sub routines,
they're usually advantageous.
Just write your whole
program inside of main.
And allow the coder to concentrate
on section of a program at a time.
The rest of the program doesn't intrude.
You can concentrate on
each part in solitude.
It's like you would go could go in a box.
This kind of stuff will
blow off your socks.
(laughing)
and tested in isolation,
this is a revelation.
Such a fascination it
calls for a celebration.
This technique deserves
adulation and replication.
Libraries, let's take the code from here
so it can be reused over there.
That's so useful it's not even fair.
You can do this all without
pulling out your hair.
Well, this was hard in 1951
when the paper was written,
but today, no, it's still not fun.
Using libraries still sucks.
Making it all work takes a bit of luck.
Now modules.
Those would be lovual.
So sub routines are bleeding edge I say,
but I will catch on I allege
and I hope that you will pledge
to use them when you're coding your next
gaming cartridge.
And here's why I consider it postmodern.
I find functions are an unused pattern
and that is my concern.
Enough of the sarcasm, but
there is this big chasm between
the promises of functions and
how they're used by us bumpkins.
Note that reuse is probably
the least important.
That at least is my argument.
So let me tell you a fable that's able.
The bitchin' depiction, somewhat fiction,
but a suitable rendition, a manifestation
that aides elucidation and a fine addition
to my collection.
I searched our code base for step one
to get a feel for how our code is done.
Here's a simple sample
that we can trample.
Step one do some stuff.
Step two, three, four
and then that's enough.
Do you really need to be ultra keen
to put step one in a sub routine?
And then give it a name like step four.
Right there is an unused
name, validate fit.
What a shame.
But the search also uncovered,
well some duplication was discovered.
How many times must the
same code be seen before
you make it a sub routine?
(laughing)
- Two.
- Two?
Anyone else?
(man mumbling)
- [Man] Three good ones.
(all laughing)
- [Man] Once per platform.
- Once per platform.
I like this question.
In interviews it's fun.
The right answer is one, right.
You don't need to see
the function more than,
you don't need to see a
block of code more than once
to give it a name, make it a function.
You don't need to be duplicated at all
in order to elevate it to a function call.
Why is this so hard?
Why is it sub routines we disregard?
Laziness, craziness?
There is no hocus pocus.
I think the answer is focus.
Too much narrow focus
in the wrong dimension.
We need to widen our function
in another direction.
We do this when we code.
You've got a problem close at hand,
your mind holds all of the context,
a complete map of the land.
So if you make a function call,
you're afraid this edifice
will start to fall.
What you built will start to crumble.
All those thoughts will jumble and tumble.
You stumble and fumble left
there to mumble and grumble.
But if I may, there's another way.
With functions you put
each small problem away.
Then there are less things in
your brain that need to stay.
You're left with functions that each
do but one thing and these
are the advantages it brings.
Reuse is the least important to me.
We had a discussion about
Postmodern error handling.
It turns out Andrew Pardoe's knowledge
of postmodernism is dazzling.
He put a link there to this
guy named Francois Lyotard.
He mentioned Lyotard,
another postmodern founder
which is where my postmodern
knowledge starts to flounder,
but applying his work to
C++ with a little bend
it's that the answer is always it depends.
You choose which ever solution you please
based on each situation's
particular priorities.
That is our curse.
There is no universal solution
that brings a problem to resolution.
There is languages like Java,
you just pick the design pattern
that others have traveled,
but we're a language where details matter,
choose what you want, smaller, faster,
understandable, maintainable
of the former, the latter,
but here the error handling
I really want to talk about.
Anyone seen a Ted Talk?
To the center of the stage I walk
to speak a bit more softly and list
some things on my
fingers, one, two, three.
So now the next thing
I say really sink in.
If they're awards, this talk should win,
(laughing)
and if I need to make it stay,
I just repeat things I say.
This talk should win.
(laughing)
this talk should win.
This talk should win.
(laughing)
So, no awards, no?
Well, nonetheless that's a trope.
A pattern or way that
is conventionally used
when you have something to say
and the often the author knows that
you know that it is used in that way.
So here are the error handling tropes,
but the real question is to
which audience you spoke.
How you tell is related to whom you tell.
If you have internal library
error, tell the author.
Maybe logging or crash dump
that the user forwards.
The calling developer is not
the same as the calling code.
That is something I feel must told.
If a developer makes a mistake there's
no code path for the error to take.
Pass a null reference,
that wasn't planned.
So to handle that error
there's no code brigand.
Instead find a transform where
the developer is informed.
You tell the calling code
when the error was foretold.
File not found.
That should be expected and
the code should be sound.
By the way exceptions are
for exceptional cases.
No that argument is baseless.
So just to be clear, just
gonna not rhyme for a second.
If I were a library and it
detects an internal error
it has to tell me the
library author somehow.
However, you figure that out.
If you call it wrong it has to tell you,
not code that called it,
but you the developer
who wrote the code.
How are you gonna get that
information to the developer
that he made a mistake?
A normal error, you call the calling code
because that probably could be able
to handle a normal error,
and then most of these things
will trickle up to the user.
So even if it's just
termination you're telling
the user something very rudely.
But my point is knowing which
person you're trying to talk to
will change the way you
communicate an error.
And you might use different
ones for every situation.
That's my thoughts on error handling.
The postmodern smart pointer.
I promised in the abstract.
So anyone want to guess what the
postmodern smart pointer is?
- [Man] Raw pointer.
- Raw pointer, close.
So close.
The postmodern smart
pointer observer pointer
is somewhat absurd.
If I was the smart pointer trope
in an ironic way, but with a value I hope.
The pointer's not mine
is a hard thing to say,
but this does it in a compilable way.
So it manifests what was
previously a comment at best.
There you go, postmodern smart pointer.
This to me is the epitome
of postmodern tweets by me.
Two readers reading the same
source may see different
values due to what each
read and wrote previously.
So if I'm an english
major, source is some text
and how it is interpreted is
based on the reader's context.
Similarly, the reader is a coder.
Their background can the
source misunderstooder,
but if the reader is a CPU
thread, then source is a piece
of memory who's value is usually a mystery
when coding anything lock free.
So this tweet is really multilevel.
When I wrote it I was being very careful.
I'm flying through here.
Sorry.
Yeah, I know where I'm at.
I'm at the conclusion.
I'm halfway through my conclusion.
In sooth, I know not
why all code's so bad.
It wearies me.
You say it wearies you.
That's the opening line
of The Coder of Venice.
I'm sure you all know it.
Venice is known for its
beautiful glassware.
So it's like its own Silicon Valley.
(audience laughs)
Okay, Silicon Marsh, swamp, Silicon Swamp,
but to really explain this properly,
I need to go back to the
beginning for a moment
and do a postmodern critique of my talk.
So let me just go back here for a second,
and now you're wondering if
I really exited anything.
(audience laughs)
All right, there we are
back to the beginning.
So a postmodern analysis
of the Post-modern C++
which is postmodern look at programming
by Tony Va-nerd, by Tony Van Eerd.
(snickering)
So, we have to ask why did
the author choose Twitter?
Anyone?
(man mumbling)
Self-contained pieces of information.
I like that.
(mumbling)
- Existing material.
- Existing material.
- Existing material, yes.
I preplanned my whole talk
by publishing it on Twitter.
(man shouting)
(all laughing)
Well, like coding, Twitter is
a very constrained platform, right,
and coding's very constrained.
You have to work within
the syntax and everything.
Also Twitter is very social
and it's all about communication.
It turns out coding is
also about communication
between developers.
So that's why I chose Twitter.
Now why Dr. Seuss?
Well, it's also constrained.
Also the author maybe
be insane, meaning me.
If nothing else it's an
example of how strict
formatting can be detrimental
to understanding something,
and honestly that just rhymed,
but I didn't mean it to.
Just once you start rhyming
things it just happens.
So, Dr. Seuss is also a constraint
and it's also about
common experience, right?
We all know Dr. Seuss or we don't.
I was talking to someone
from Europe who had know idea
what I was talking about.
Doesn't know who Dr. Seuss is,
but in North America we
all think, I just assume
we all know who Dr. Seuss is.
We run into this problem in code.
We assume that people have
common experiences as us.
They have the same background.
They should know you leave a comment,
they should know what
you're talking about,
that kind of thing,
and note that I actually left
a reference to Dr. Seuss
in my opening remark.
It's about having a wonderful awful idea.
And tropes, right.
Why do they want to talk about tropes?
Again it's common experience.
Tropes which are just patterns in code
only work if you have a common experience.
Graphs.
Why graphs?
Well, how can you have
a talk without graphs?
That's obvious, but I have graphs.
All my graphs were
basically devoid of content
because it's like the word foo.
My graphs were foo.
It was there for formatting.
A talk has to have graphs,
therefore I followed the
formatting rules of the talk.
What I really was talking about
in the graphs was formatting.
(man mumbling)
This whole thing is a talk
on meaninglessness I'm sure,
and differance, what's up with that?
That is in some sense syntax, right?
You take a sentence and
you look at the words
and you replace words with other words
and it's trying to get at
the meaning of a single word
and the point of differance
is you can't get the meaning
of a single without understanding
the meaning of all other words.
All other words in,
you start with one word
and think of the other
words that can be replaced
and you think of the definitions
that this word is based on
or it's based on other
words and it defers forever,
and we have that problem in code a lot.
It's just like one small piece of code
you have to understand so
much else to understand
a small line of code, because
it's all about context.
Bruce Lee, what's up with that?
It's a reference right?
What's up with all these references?
We'll get back to references.
Deconstruction is another weird thing
that not only is it about
syntax because you replace
pieces of a sentence with
words that can be substituted
which in coding, you change one thing
and your code completely changes.
If you're lucky it's a compiler error
and otherwise you just
get something you didn't
expect just because you
change one letter sometimes.
But deconstruction is there
for a way to get a new perspective.
You look at something and then you
try to look at it in different ways.
It's a way of thinking.
Van Gogh is also a different
way of thinking about things
and it's also just another
reference I threw in,
and the it talked about
formatting, but I'm linking
formatting with communication
which you can argue with
whether we have these constraints that
we have to have code that compiles,
yet I'm trying to communicate with you.
So why tie me to down how
I'm going to communicate?
Let me format which ever way I think
will communicate best in the situation,
and bugs.
Finally we get to the problem at hand,
or at least a manifestation
of the problem at hand.
What is the real source of the problem?
Bugs are just the result
of some underlying problem,
and then WTF.
Why do I do things like that?
I'm trying to stretch your
mind out a little bit, right?
Think of things a different way.
See things differently,
and be aware of yourself
and aware of the big picture
while you're coding.
You should be aware of
what the whole context is,
and I just want to mess with
your brain a little bit.
That's the point.
Then I brought up, I like to
be sarcastic about this paper
as if it's brand new technology.
It's from 1951, but is it
a solution to the problem?
Because I really think we
don't use enough functions
and maybe it's that simple.
It's like Monty Python's the
answer to The Meaning of Life
Monty Python's thing was people
are not wearing enough hats.
So that's my conclusion.
I review tons of code and one of the
main things I say is
put that in a function.
So I don't care what classes.
So many other things.
It's just take this code,
put it in a function,
and you know is it that simple?
Just the world needs more functions.
Okay, now wait a second.
Now my postmodern analysis of my talk
about is also using references.
So let me give you a postmodern comment on
the postmodern analysis
of my postmodern talk.
This is a reference to Monty
Python's The Meaning of Life
as I mentioned, but where
do these references end?
Should reference the Gabon paper here,
the crappy Gabon paper?
This is of course a reference to a,
this is a reference to a comment about
a reference in a published paper.
Let me explain that.
(laughing)
Yeah, my explanation is
that it's a reference to
a comment in a published
paper that the comment
got mistakenly left.
They were thinking should
I put a reference here?
That's the exact quote.
Should we reference
the crappy Gabon paper?
But because of our shared experiences,
if anyone has seen this quote before,
there's a good chance you
saw it in this paper about
Burritos for the Hungry Mathematician
because he quotes it in here,
and this is a paper of course on MONADS.
(audience laughs)
Also, it seems to harken back to the 1999,
everything's connected.
So how is it possible to
understand that many references
in a piece of code.
Same problem.
Stop using references and pointers.
Use value types.
(laughing and applauding)
So real conclusions.
I did go really fast.
Okay, that was 200 slides.
We have context.
That's the big theme here is
what context are you working
and how do you maintain that sense of
context when you're
coding and communication.
You have to communicate with
the compiler first of all,
but you're going through the compiler
to actually communicate
with the computer right?
That's what you're trying
to tell the computer
to do something for you,
and that is for the sake
of the end user who you're
really trying to communicate
to, but during all that,
you also have to communicate
to the programmer, right?
How do you do all that at once?
It's like, maybe practice,
I don't know.
Shakespeare did all this
stuff in iambi pentameter.
That was my other choice.
I was going to do this
in iambic pentameter,
but he still communicated
you know the human condition.
So communication is hard,
but we should try to do it
and then we have all these constraints
and format and syntax and ambiguity
and I put patterns on both sides of the,
one side is kind of the problems
and the other side is possible solutions.
This is the abstract of my talk,
and the main is that when you're coding,
we think so linearly on
a problem at hand, right?
You're just focused on
this path of the code
through the code base.
It's like bug happened here.
You went down here da, da, da, da,
add that if statement,
fix the bug and you're not
thinking of the real coding
graph is much more complicated
and we just put blinders on
and we need to think more like this,
and the goal of this talk was not
actually for you to watch me.
The goal was for me to watch
you and for you to watch you.
So my goal was did you follow along?
Were you picking up these
strange ways of thinking?
Are you starting to make
rhymes in your head?
So I have this theory that you
can't teach good programming.
It's a way of thinking.
It's your personality is in your code,
and I would like to be proven wrong.
This is my first attempt
to prove myself wrong
is that you can teach people
to code a different way
and the way to do that is to
make them think differently.
So I wanted, there's no strike
through in the formatting
of our abstracts.
My real goal is to change the way we think
because if we can't
change the way we think,
we can't change the way we
think about programming.
So that's all.
It's trying to think in this,
try not to be stuck in
one mode in thinking.
We think so linearly and
we shouldn't be doing that.
And that is I've gone way too
fast and thanks to Dr. Seuss.
Today is done.
Today is gone.
Today was fun.
Tomorrow is another one.
And I want to apologize to
the C++ video access team
who are trying to
translate all of C++ talks.
I don't know.
(audience laughs)
I don't know how they're
going translate this talk.
Any questions?
(applause)
Yes.
- [Man] So in the slide with
the various if statements
and the color combinations provided,
why did you skip the
obvious red if, blue if?
- One fish, two fish.
- [Man] Yes.
- I'm never gonna give this talk again,
but I will write that down, thank you.
(snickering)
I failed.
- [Man] What is the crappy Gabon paper?
- The crappy Gabon, I don't know.
(audience laughs)
The paper is something to do
with whatever it said there.
Biology of invertebrate things
in the ocean or something.
- [Man] I may have a way
for you to kill time.
Do you have the Bruce Lee
slide deck on your laptop?
- You know, I have
bonus slides right here.
- [Man] Of course you do.
(audience laughs)
- I should've mentioned that.
(man mumbling)
Yes still good.
- [Man] All right so you
totally rest all of on engineers
employing trips,
but how can we
(laughing)
in your sharp mind these tropes
into our language enshrine?
Modules perchance come to mind,
but others maybe can you find?
- Others maybe?
(applause)
What was the last bit of
the question actually?
- [Man] Do you want it in rhyme or not?
(laughing)
- No, because obviously rhyming,
no one understands what you're saying.
(audience laughs)
- It's just that
you were talking about tropes
and talking about conventions
or programming using
conventions to make our
programs more readable
and more understandable.
That we have things going
into the language to enshrine
things like modules are
kind of an in language way
of hair guards for example
that encode good practice
into the actual language semantics itself.
Do you see anything else
coming up that might
also take things which
are now conventional
and turn them into something which
are actually part of the language?
- Yeah, I think we try
to do that all the time.
I have two thoughts on that.
Like variant is an example, right?
We made a variant class,
but it might be good to
have variant built into
the language, right?
(laughing)
- [Man] How do you really feel?
- Do I have?
My phone is beeping at me
to remind me of a talk.
(audience laughs)
But the other part is paradigms and tropes
are both good and bad, right,
because what you always end up
doing is going to a code base
where they're using all these paradigms
that you're like what are you guys doing?
Why do you code like this?
And like we code like this because
we've always coded like this,
and you can trace it back to one guy
who started coding that way,
and as someone else
coming into a code base
you're like these are all,
and I've done this before where I've
tried to use different
paradigms in a code base
and manager, that's the
case where my manager said
we have enough paradigms.
It's like the code I was
writing wasn't wrong.
It might have actually been better,
but it just didn't fit
with the current code base.
He was like people are gonna
read this and understand
what you're doing, just do it the way
the rest of our code does it.
Sometimes that's a good thing,
sometimes that's a bad thing.
It's good so that people can
understand things easier,
but also you're making an
assumption that people are
going to understand because you're like
everyone knows this pattern.
No they don't.
- [Man] Thank you.
- I have bonus slides.
I'd forgot I had bonus slides.
They were just here from last time.
C++ Koans.
Master is says must do x first but why?
Check git.
After a week of finding
nothing in the archives,
the student was enlightened.
(laughing)
So, if you all understand Koans, right.
They're like short little
stories where there's
an enlightenment at the end
and I had this crazy idea
that I would write C++
Koans and I thought wow,
that's gonna be really hard
to do and then I thought
no, I have to do it within 140 characters.
So that's insane.
I won't be able to do it, but
I've got like five or six.
Does anyone understand the
enlightenment in this story?
- [Man] The comment is wrong.
- The comment is wrong.
(man mumbling)
The comment wasn't wrong in this case.
This is a true story by the way.
The comment was right,
but there was something wrong about it.
I'm not supposed to give,
the other part of a Koan
is you're not supposed to explain them,
yet I'm here.
Because you really don't
feel the, you don't get the
enlightenment unless you
spend the week looking
through git to understand the comment.
Then you become enlightened
because you spend a week in git
and you find nothing, then you're like ha.
Anyone enlightened from that?
- [Man] Can you hear me?
- Yes.
(man mumbling)
Yeah, the code does x
first and then it does y.
Just like the comment
says, must do x first.
What's the problem with
the code or the comment?
It doesn't explain why, thank you.
There's the enlightenment.
I actually did this.
I had a piece of code that
said must do this first
and it was causing a bug.
I had to switch the code around
to do the other one first,
and I'm like but why?
It says right here do this first
and I'm like I can't change
it but it's causing a bug.
I have to change it.
So I went looking through
Perforce and you know back
before you had get blame
and all those other stuff.
Traced it back, it took me tons of time,
and I finally found who
put that comment in.
It was me.
(audience laughs)
So now all my comments
include the word otherwise.
This is also a true story.
Lock free master we need queue.
He searched the code base,
then typed thread safe
queue equals mutexed queue T.
Anyone enlightened by that?
You must be.
You know, this totally
makes sense to you right?
Yes.
(man mumbling)
Titus do you have a comment
that would excite us?
(audience laughs)
I was prepared.
- [Man] Lock free types are
a beautiful parlor trick.
(laughing)
- Lock free types are a
beautiful parlor trick, yes.
This really happened.
People came to me and
said we had a problem.
We can use lock free queue
here and they just stared at me
like I'm gonna write one now
because I do lock free programming,
and I went here's a mutexed queue.
It works, we're done, right.
Go measure if you think you
need something better than that.
The Rule of Zero.
Explain the Rule of Zero.
Study the pointers of
Masters Hinnant and Dimov.
They have destructors.
They don't follow the Rule
of Zero as they should.
I'll just keep going.
(audience laughs)
Near sprint end Master found
them arguing N versus log N.
She typed a solution.
It was N squared.
One left in disgust,
the other enlightened.
Is that good?
We're all good with that?
Yeah, you're just nodding.
They can take a gander at Chandler.
Okay, I've written one since then,
but it's not in my slides.
It's somewhere in Twitter.
You can find one more C++ Koan
hiding in Twitter somewhere
and I am gonna say I have
no more bonus slides.
Yes.
That's it.
(applause)
