3 ms·

The problem with knowing too many languages is that soon the syntax starts blending with each other, and context switches take time.

by ajays 16y ago

malkia 16y ago
Actually it helped me realize certain things in other libs. For example using std::<pair> more after spending time with Common Lisp. Also it made me realized that certain building blocks, patterns, etc. are not that great when looked through a different view. For example the "factory" pattern is needed in C++, because objects can be allocated on the stack... Wait... what? Well, because C++ allows allocation of objects on the stack, obviously one cannot think in it, as if "new" would've returned object with different size than the one declared. e.g. "new SomeClass()" is known by the compiler how much space would take, hence "SomeClass someObject;" is known in advance and can be allocated on the stack. Cool, isn't.... Actually not so cool - because of that you can't return proxied objects, hidden implementation, etc... Hence you need factory - instead of "new SomeClass" -> CreateSomeClass() function that might return object of different size... Where I got aware of this - by spending some time with Objective C and it's objects. Then comes the holly OOP, especially the C++ way - but then one discovers lua, javascript... Or Common Lisp... and understands - "protected", "private" are not that important, and the GOF patterns are not that needed. Okay, so you go back at your work to code in C++, and just take it easier, because you have realized there is no point going hard-core and doing it the C++ way all the time. Hell it's even okay to have this macro called "HASHED( "SomeGameResource", 0x123123 )" that... gets preprocessed by external tool, that replaces 0x123123 with the hash code of "SomeGameResource" and puts it back in the source code. #ifdef DEBUG #define HASHED(s,c) hashed(s) // e.g. call function in debug to return the hash-code #else #define HASHED(s,c) c // replaced with the precalculated value #endif Now try doing that with templates.... But my point is - there is no need - just use an external tool that does it for you. Inform your programmers that if they want to change HASHED("BlahBlah", 0x123123) to HASHED("BlahBlah2", 0x123123) then they have to run it through a tool (or have such step), or just make them use the debug version. Or change the language... Joke! You are doing this for the Nintendo DS - "C/C++" is the only viable option for large project.

The problem with knowing too many languages is that soon the syntax starts blending with each other, and context switches take time.

by ajays 16y ago

The problem with knowing too many languages is that soon the syntax starts blending with each other, and context switches take time.

malkia 16y ago

Actually it helped me realize certain things in other libs. For example using std::<pair> more after spending time with Common Lisp. Also it made me realized that certain building blocks, patterns, etc. are not that great when looked through a different view. For example the "factory" pattern is needed in C++, because objects can be allocated on the stack... Wait... what? Well, because C++ allows allocation of objects on the stack, obviously one cannot think in it, as if "new" would've returned object with different size than the one declared. e.g. "new SomeClass()" is known by the compiler how much space would take, hence "SomeClass someObject;" is known in advance and can be allocated on the stack. Cool, isn't.... Actually not so cool - because of that you can't return proxied objects, hidden implementation, etc... Hence you need factory - instead of "new SomeClass" -> CreateSomeClass() function that might return object of different size... Where I got aware of this - by spending some time with Objective C and it's objects. Then comes the holly OOP, especially the C++ way - but then one discovers lua, javascript... Or Common Lisp... and understands - "protected", "private" are not that important, and the GOF patterns are not that needed. Okay, so you go back at your work to code in C++, and just take it easier, because you have realized there is no point going hard-core and doing it the C++ way all the time. Hell it's even okay to have this macro called "HASHED( "SomeGameResource", 0x123123 )" that... gets preprocessed by external tool, that replaces 0x123123 with the hash code of "SomeGameResource" and puts it back in the source code. #ifdef DEBUG #define HASHED(s,c) hashed(s) // e.g. call function in debug to return the hash-code #else #define HASHED(s,c) c // replaced with the precalculated value #endif Now try doing that with templates.... But my point is - there is no need - just use an external tool that does it for you. Inform your programmers that if they want to change HASHED("BlahBlah", 0x123123) to HASHED("BlahBlah2", 0x123123) then they have to run it through a tool (or have such step), or just make them use the debug version. Or change the language... Joke! You are doing this for the Nintendo DS - "C/C++" is the only viable option for large project.