Nothing bad would happen. The compiler would be able to infer the type is float in this case. Strong typing is not always necessary or helpful.

1. Dear compiler: Please don't be my Nanny
Speaker Name
Dino Dini NHTV University of Applied Sciences

2. Nanny says:

3. Nanny says:
● Don't you ever use goto

4. Nanny says:
● Don't you ever use goto
● Regard preprocessors as bad

5. Nanny says:
● Don't you ever use goto
● Regard preprocessors as bad
● Might we suggest always saying new

6. 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

7. 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?

8. 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

9. 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

10. 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.

11. Don't you ever use goto

12. 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:

13. 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

14. 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

15. 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

16. 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

17. 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.

18. 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.

19. 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...

20. Regard preprocessors as bad

21. Regard preprocessors as bad
I can decide for myself when it is appropriate to use macros or conditional
compilation.

22. Regard preprocessors as bad
I can decide for myself when it is appropriate to use macros or conditional
compilation.
Java does not even allow
conditional compilation,
and it is hilarious, the
hoops that you have to
jump through as a result.

23. Regard preprocessors as bad
I can decide for myself when it is appropriate to use macros or conditional
compilation.
Java does not even allow
conditional compilation,
and it is hilarious, the
hoops that you have to
jump through as a result.

24. Regard preprocessors as bad
Some legitimate uses:

25. Regard preprocessors as bad
Some legitimate uses:
● Porting legacy code

26. Regard preprocessors as bad
Some legitimate uses:
● Porting legacy code
● Avoiding repetitive boilerplate

27. Regard preprocessors as bad
Some legitimate uses:
● Porting legacy code
● Avoiding repetitive boilerplate
● Abstracting of identifiers

28. Regard preprocessors as bad
Some legitimate uses:
● Porting legacy code
● Avoiding repetitive boilerplate
● Abstracting of identifiers
● Implementing support for multitasking

29. 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

30. 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

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

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

33. Might we suggest always saying new

34. 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.

35. 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));

36. 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:

37. 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....

38. Might we suggest always saying new
And it's not as if C# is consistent, is it?

39. 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.

40. Might we suggest always saying new
DebugOut ( fluffyKitten.name );

41. Might we suggest always saying new
DebugOut ( fluffyKitten.name );

42. Fact is OOP should make you glad
Object orientated programming did not turn out to be the
cure for our ills.

43. Fact is OOP should make you glad
Are objects really the best building blocks of code?

44. Fact is OOP should make you glad
Are objects really the best building blocks of code?
How about keeping data and functionality separate
instead?

45. 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.

46. 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.

47. Fact is OOP should make you glad
This means more...

48. Fact is OOP should make you glad
This means more...

49. So you want to overload?

50. So you want to overload?
Overloading functions and operators really can be very
useful, but many languages refuse to support them for
dubious reasons.

51. 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.

52. So you want to overload?
Lets compare two pseudo code fragments:

53. So you want to overload?
Lets compare two pseudo code fragments:
Vector3 N = ( pos1 - pos2 ) . Normalise();
pos1 += N * speed;

54. 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 ));

55. 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?

56. La la land's where weak typing goes

57. La la land's where weak typing goes
The only reason for strong typing is, let's face it, performance.

58. 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?

59. 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

60. La la land's where weak typing goes
float f = 10.5;

61. La la land's where weak typing goes
float f = 10.5;
It's a constant! What on earth does the error serve?

62. La la land's where weak typing goes
float f = 10.5;
Here's what would happen if you relaxed...

63. La la land's where weak typing goes
float f = 10.5;
Here's what would happen if you relaxed...
Nothing....

64. La la land's where weak typing goes
And this:
Tank tank = GetObject("Tank") as Tank;

65. La la land's where weak typing goes
And this:
Tank tank = GetObject("Tank") as Tank;
OK, got it, it's a Tank!

66. La la land's where weak typing goes
And this:
Tank tank = GetObject("Tank") as Tank;
OK, got it, it's a Tank!

67. La la land's where weak typing goes
And this:
Tank tank = GetObject("Tank") as Tank;
OK, got it, it's a Tank!

68. 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

69. Ti's right to make everything private

70. 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#.

71. 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;
// ...
}

72. 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...

73. 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;
// ...
}

74. Ti's right to make everything private
Of course, after a while you get sick of having your compiles fail....

75. 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.

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

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

78. 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.

79. 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

80. 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.

81. 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

82. Ti's right to make everything private
What you really want is interfaces that can only be called by
authorised modules...

83. 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()?

84. 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()?

85. And that brings us back to Don't.
● Don't think you know my needs better than me

86. And that brings us back to Don't.
● Don't think you know my needs better than me
● Don't take my tools away

87. 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

88. 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

89. 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

90. 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

91. 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

92. Don’t Bring Me Down