The amount of people nitpicking about the brand of pseudocode or arguing the question is tricky reminds me of some coworkers, and not the good kind.
If you belong to the above category, try to learn some new programming language / read about some algorithm descriptions (not implementation) and go out take some sun. The question is super intuitive if you’re not stuck to a single paradigm or language.
So I teach coding to idiots. Confusing or poorly defined abstractions in pseudocode are bad. If you want people to infer useful information from pseudocode, and learn good practices from it, you need to treat it as if there a real underlying class structure written with good practices, or even better, make it comply to some actual language which does that. If you want to imply that this is a member of string, something like string.len_chars is way better imo because it captures the idea of a string being an array<char>. Then the next question can be about string.len_bytes (watch the wheels turn!). That naturally transitions nicely into object oriented paradigms of object containers/storage being at once a templated abstraction with a stride and depth, and also a physical thing in memory.
Better. Of course, it’s just built over top, so you can still get JavaScript issues in TypeScript, and it’s not necessarily going to be obvious. This is particularly an issue if you call JavaScript libraries, which I’m told is standard practice.
You have to take into account that a big company game is going to by much harder to implement than just a small hobby team game simply because of all the people involved.
What can 5 people do in a year may take more for 500 people, just because of the management overhead. And if that management sucks, it will end up doing way more things it was required to do, yet the original request will not be done well.
I like how specifically this relates to my experience with the discount factor gamma in Reinforcement Learning. Like, pretty close to the exact numbers (though missing 0.99 and 0.999)
My experience in going from C to C++ was different: if you're not converting everything from mallocs with custom addressing systems to the collections framework, you're not living.
My experience with C++ was when C++ was a relatively new thing. Practically the only notable feature provided by the standard library, was that unholy abuse of bit shift operators for I/O. No standard collections or any other data types.
And every compiler would consider something else a valid C++ code or interpret the same code differently.
I am little bit prejudiced since then… and that is probably where the author is coming from too.
Then things were just getting more complicated (templates and other new syntax quirks), to fill the holes in attempts to make C a 'high level language'.
I like Javascript… but it is certainly an unholy amalgamation of mismatched parts that, in the end, can get pretty much anything done if you don’t mind 100+ node dependencies.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.