Dear compiler: Please don't be my Nanny

Speaker NameDino Dini NHTV University of Applied Sciences

Nanny says:

Nanny says:

●Don't you ever use goto

Nanny says:

●Don't you ever use goto●Regard preprocessors as bad

Nanny says:

●Don't you ever use goto●Regard preprocessors as bad●Might we suggest always saying new

Nanny says:

●Don't you ever use goto●Regard preprocessors as bad●Might we suggest always saying new●Fact is OOP should make you glad

Nanny says:

●Don't you ever use goto●Regard preprocessors as bad●Might we suggest always saying new●Fact is OOP should make you glad●So you want overload?

Nanny says:

●Don't you ever use goto●Regard preprocessors as bad●Might we suggest always saying new●Fact is OOP should make you glad●So you want overload?●La la land's where weak typing goes

Nanny says:

●Don't you ever use goto●Regard preprocessors as bad●Might we suggest always saying new●Fact is OOP should make you glad●So you want overload?●La la land's where weak typing goes●Ti's right to make everything private

Nanny says:

●Don't you ever use goto●Regard preprocessors as bad●Might we suggest always saying new●Fact is OOP should make you glad●So you want overload?●La la land's where weak typing goes●Ti's right to make everything private●And that brings us back to Don't.

Don't you ever use goto

Don't you ever use goto

Contrary to popular belief, goto is not evil. Sometimes it can be the right tool for the job, especially when:

Don't you ever use goto

Contrary to popular belief, goto is not evil. Sometimes it can be the right tool for the job, especially when:

● Prototyping non production code

Don't you ever use goto

Contrary to popular belief, goto is not evil. Sometimes it can be the right tool for the job, especially when:

● Prototyping non production code● Trying to fix bugs in finished code with minimal risks

Don't you ever use goto

Contrary to popular belief, goto is not evil. Sometimes it can be the right tool for the job, especially when:

● Prototyping non production code● Trying to fix bugs in finished code with minimal risks● Porting legacy code

Don't you ever use goto

Contrary to popular belief, goto is not evil. Sometimes it can be the right tool for the job, especially when:

● Prototyping non production code● Trying to fix bugs in finished code with minimal risks● Porting legacy code● Implementing state machines

Don't you ever use goto

If the code would have been clearer with a goto, then perhaps a goto was the best thing to use.

Don't you ever use goto

If the code would have been clearer with a goto, then perhaps a goto was the best thing to use.

Java does not support goto, but still reserves the keyword. Adding goto support would take minutes, and would not end the world.

Don't you ever use goto

If the code would have been clearer with a goto, then perhaps a goto was the best thing to use.

Java does not support goto, but still reserves the keyword. Adding goto support would take minutes, and would not end the world.

I Feel a disturbance in the Force...

Regard preprocessors as bad

Regard preprocessors as bad

I can decide for myself when it is appropriate to use macros or conditional compilation.

Regard preprocessors as bad

I can decide for myself when it is appropriate to use macros or conditional compilation.

Java does not even allowconditional compilation,and it is hilarious, thehoops that you have tojump through as a result.

Regard preprocessors as bad

I can decide for myself when it is appropriate to use macros or conditional compilation.

Java does not even allowconditional compilation,and it is hilarious, thehoops that you have tojump through as a result.

Regard preprocessors as bad

Some legitimate uses:

Regard preprocessors as bad

Some legitimate uses:

●Porting legacy code

Regard preprocessors as bad

Some legitimate uses:

●Porting legacy code●Avoiding repetitive boilerplate

Regard preprocessors as bad

Some legitimate uses:

●Porting legacy code●Avoiding repetitive boilerplate●Abstracting of identifiers

Regard preprocessors as bad

Some legitimate uses:

●Porting legacy code●Avoiding repetitive boilerplate●Abstracting of identifiers●Implementing support for multitasking

Regard preprocessors as bad

Some legitimate uses:

●Porting legacy code●Avoiding repetitive boilerplate●Abstracting of identifiers●Implementing support for multitasking●Registration of string to object mapping

Regard preprocessors as bad

Some legitimate uses:

●Porting legacy code●Avoiding repetitive boilerplate●Abstracting of identifiers●Implementing support for multitasking●Registration of string to object mapping● And much, much more stuff that's not computer sciency,

but helps you Get Stuff DoneTM

Regard preprocessors as bad

C# learned the lesson of conditional compilation, but still will not let me use macros. Which means more...

Regard preprocessors as bad

C# learned the lesson of conditional compilation, but still will not let me use macros. Which means more...

Might we suggest always saying new

Might we suggest always saying new

It is a sad fact of life that programs have to allocate memory, which is messy and slow and affects performance.

But to rub it in all the time is just plain senseless.

Might we suggest always saying new

It is a sad fact of life that programs have to allocate memory, which is messy and slow and affects performance.

But to rub it in all the time is just plain senseless.

Vector3 vec = current + new Vector3(1,2,3);

DoSomethingImportant( new Vector3(a,b,c),new Vector3(d,e,f),new Vector3(g,h,i));

Might we suggest always saying new

This is what would actually happen if experienced programmers were not constantly reminded that doing stuff causes memory allocations:

Might we suggest always saying new

This is what would actually happen if experienced programmers were not constantly reminded that doing stuff causes memory allocations:

Nothing....

Might we suggest always saying new

And it's not as if C# is consistent, is it?

Might we suggest always saying new

And it's not as if C# is consistent, is it?

You are forced to say new all the time, but can then create accessors that could actually end the world through what looks like an innocent variable read.

Might we suggest always saying new

DebugOut ( fluffyKitten.name );

Might we suggest always saying new

DebugOut ( fluffyKitten.name );

Fact is OOP should make you glad

Object orientated programming did not turn out to be the cure for our ills.

Fact is OOP should make you glad

Are objects really the best building blocks of code?

Fact is OOP should make you glad

Are objects really the best building blocks of code?

How about keeping data and functionality separate instead?

Fact is OOP should make you glad

Are objects really the best building blocks of code?

How about keeping data and functionality separate instead?

The first thing an architect seems to do with OOP is separate data from functionality through interfaces.

Fact is OOP should make you glad

Are objects really the best building blocks of code?

How about keeping data and functionality separate instead?

The first thing an architect seems to do with OOP is separate data from functionality through interfaces.

Compilers are generally designed around the OOP model, making it harder to solve programming problems in other ways.

Fact is OOP should make you glad

This means more...

Fact is OOP should make you glad

This means more...

So you want to overload?

So you want to overload?

Overloading functions and operators really can be very useful, but many languages refuse to support them for dubious reasons.

So you want to overload?

Overloading functions and operators really can be very useful, but many languages refuse to support them for dubious reasons.

Javascript does not even support overloaded functions.

So you want to overload?

Lets compare two pseudo code fragments:

So you want to overload?

Lets compare two pseudo code fragments:

Vector3 N = ( pos1 - pos2 ) . Normalise();pos1 += N * speed;

So you want to overload?

Lets compare two pseudo code fragments:

Vector3 N = ( pos1 - pos2 ) . Normalise();pos1 += N * speed;

// or

Vector3 N = NormaliseVector3( sub2Vector3( pos1,pos2 ));

AddToVector3( ScaleVector3( N, speed ));

So you want to overload?

Lets compare two pseudo code fragments:

Vector3 N = ( pos1 - pos2 ) . Normalise();pos1 += N * speed;

// or

Vector3 N = NormaliseVector3( sub2Vector3( pos1,pos2 ));

AddToVector3( ScaleVector3( N, speed ));

Questions?

La la land's where weak typing goes

La la land's where weak typing goes

The only reason for strong typing is, let's face it, performance.

La la land's where weak typing goes

The only reason for strong typing is, let's face it, performance.

Why, oh why, does C# insist I put an f on my floats?

La la land's where weak typing goes

The only* reason for strong typing is, let's face it, performance.

Why, oh why, does C# insist I put an f on my floats?

float f = 10.5;// come on compiler, be sensible// It feels like I spend most of my// fixing this when you complain

* Disclaimer: This is a rant

La la land's where weak typing goes

float f = 10.5;

La la land's where weak typing goes

float f = 10.5;It's a constant! What on earth does the error serve?

La la land's where weak typing goes

float f = 10.5;Here's what would happen if you relaxed...

La la land's where weak typing goes

float f = 10.5;Here's what would happen if you relaxed...

Nothing....

La la land's where weak typing goes

And this:Tank tank = GetObject("Tank") as Tank;

La la land's where weak typing goes

And this:Tank tank = GetObject("Tank") as Tank;

OK, got it, it's a Tank!

La la land's where weak typing goes

And this:Tank tank = GetObject("Tank") as Tank;

OK, got it, it's a Tank!

La la land's where weak typing goes

And this:Tank tank = GetObject("Tank") as Tank;

OK, got it, it's a Tank!

La la land's where weak typing goes

And this:Tank tank = GetObject("Tank") as Tank;

OK, got it, it's a Tank!

This is a tank

Ti's right to make everything private

Ti's right to make everything private

It started innocently enough, as:

class Foo {public:

int share_this;int share_that;// ...

}

But then this was seen as too easy by the designers of C#.

Ti's right to make everything private

Since they decided that sharing information should be painful to a programmer, they insisted on:

class Foo {public int share_this;public int share_that;

// ...}

Ti's right to make everything private

Since they decided that sharing information should be painful to a programmer, they insisted on:

class Foo {public int share_this;public int share_that;

// ...}

// uh uh, wait...

Ti's right to make everything private

Since they decided that sharing information should be painful to a programmer, they insisted on:

public class Foo {public int share_this;public int share_that;

// ...}

Ti's right to make everything private

Of course, after a while you get sick of having your compiles fail....

Ti's right to make everything private

Of course, after a while you get sick of having your compiles fail....

...So you just put public in front of everything.

Ti's right to make everything private● Typing public all the time is tedious

Ti's right to make everything private● Typing public all the time is tedious● It slows you down when you forget

Ti's right to make everything private● Typing public all the time is tedious● It slows you down when you forget● 95% of the code you write will never be part of some giant

architecture.

Ti's right to make everything private● Typing public all the time is tedious● It slows you down when you forget● 95% of the code you write will never be part of some giant

architecture.● When you a prototyping you often do not know in advance

what you want to be public

Ti's right to make everything private● Typing public all the time is tedious● It slows you down when you forget● 95% of the code you write will never be part of some giant

architecture.● When you a prototyping you often do not know in advance

what you want to be public● Because C# does not support the friend keyword, there is no

easy way to make data visible only to certain objects, so you make everything public anyway.

Ti's right to make everything private● Typing public all the time is tedious● It slows you down when you forget● 95% of the code you write will never be part of some giant

architecture.● When you a prototyping you often do not know in advance

what you want to be public● Because C# does not support the friend keyword, there is no

easy way to make data visible only to certain objects, so you make everything public anyway.

● It's not even the right kind of privacy

Ti's right to make everything private

What you really want is interfaces that can only be called by authorised modules...

Ti's right to make everything private

What you really want is interfaces that can only be called by authorised modules...

Maybe it would be good if only certain modules are authorised to call AddFunds()?

Ti's right to make everything private

What you really want is interfaces that can only be called by authorised modules...

Maybe it would be good if only certain modules are authorised to call AddFunds()?

And that brings us back to Don't.

● Don't think you know my needs better than me

And that brings us back to Don't.

● Don't think you know my needs better than me● Don't take my tools away

And that brings us back to Don't.

● Don't think you know my needs better than me● Don't take my tools away● Don't restrict creativity

And that brings us back to Don't.

● Don't think you know my needs better than me● Don't take my tools away● Don't restrict creativity● Don't complicate the simple in the name of an ideal

And that brings us back to Don't.

● Don't think you know my needs better than me● Don't take my tools away● Don't restrict creativity● Don't complicate the simple in the name of an ideal● Don't stop me doing what needs to be done

And that brings us back to Don't.

● Don't think you know my needs better than me● Don't take my tools away● Don't restrict creativity● Don't complicate the simple in the name of an ideal● Don't stop me doing what needs to be done● Don't keep arguing with me

And that brings us back to Don't.

● Don't think you know my needs better than me● Don't take my tools away● Don't restrict creativity● Don't complicate the simple in the name of an ideal● Don't stop me doing what needs to be done● Don't keep arguing with me● Don't get in my way

Don’t Bring Me Down