Dear compiler please don't be my nanny v2
Download as pptx, pdf0 likes1,292 views
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.
Dear compiler please don't be my nanny v2
- 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. Dont Bring Me Down