Yo whatup

  • 0 Posts
  • 41 Comments
Joined 2 years ago
cake
Cake day: September 28th, 2023

help-circle
  • What ramdon ass language could they possibly be pulling out of their ass for you to he completely unable to write a for loop? I’ve yet to see a for loop, or really any sort of loop that doesn’t look pretty much exactly like the standard C style for loop

    for(int x = 0; x < z; x++) {
    }
    

    If you have a C style language with iterator for loops like C++, Java and friends you almost certainly have this syntax

    for(int x : numbers) {
    }
    

    Python has exclusively iterator for loops with this syntax

    for x in range(z)
    

    The only real difference is that instead of a colon : you use the in token.

    At best I can see the need for a quick refresh on what the exact syntax is but if your a senior any languages you actually use should have a template for junk like this. I don’t think I’ve manually written a loop in ages, I just type out iter for an iterator for loop or when I rarely need an index fori and the rest gets stamped out for me.

    If your being tested on random languages you can simply just not be familiar with a language. I haven’t touched Zig once but I’d totally be down to learn it. Everybody whos got a couple languages under their belt knows how easy it is to pick up new ones.


  • So your writing a game. This game has what I’m going to call “entities” which are the dynamic NPCs and such objects. So these objects are most easily conceptualized as mutable things. Why mutable? Well they move around, change states depending on game events ect. If this object is immutable you’d have to tie the in world representation to a new object, constantly just because it moved slightly or something else. This object is mutable not just because it’s easier to understand but there are even efficiency gains due to not needing to constantly create a new version just because it moved a little bit.

    In contrast the object which holds the position data (in this case we’ll have 3 doubles x, y, z) makes a lot of sense as an immutable object. This kind object is small making it cheap to replace (it’s just 3 doubles, so 3*64 bits or a total of 24 bytes) and it’s representing something that naturally makes sense as being immutable, it’s a set of 3 numbers.

    Now another comparison your typical dynamic array type container (this is your std::vector std::vec ArrayList and friends). These are mutable objects mainly due to efficiency (it’s expensive to copy the contents when adding new values) yet they also are easier to conceptualize when mutable. It’s an object containing a collection of stuff like a box, you can put things in, take stuff out but it’s still the same box, just it’s contents have changed. If these objects are immutable to put something into the box you must first create a brand new box, and create a copy of the old boxes contents, and then put your new item into the box. Every time. Sometimes this kind of thing makes sense but it’s certainly not a common situation.

    Some functional languages do have immutable data structures however in reality the compiler usually does some magic and ends up using a mutable type as it’s simply so much more efficient.







  • Eh? How’s that work. I’m not going to sit here and say there isn’t too many factories in Java but as a concept it’s extremely useful. You hand off a “factory” to something which actually creates the object. This is really useful in for example serialization. How so? You could register factories (mapped to some sort of ID) which get passed the serialized data and return some sort of created object. Now the core serialization code doesn’t know nor care how exactly any particular type gets serialized. Pretty nifty huh?

    Some languages have better ways to encapsulate this functionality but that’s what the factory concept is


  • No python is statically typed. You have type hints, which makes the language tolerable but like their name implies it’s a hint at the type. You can perfectly legally pass in something completely different that doesn’t conform whatsoever.

    The primary thing static languages provide is static typing, that being the ability to determine before runtime that all the types are valid. A good example of this is how C++ programs will refuse to compile if you try to invoke a method that doesn’t exist on the type. That’s because it’s statically typed. At compile time you know that the code is wrong. Dynamic languages fundamentally don’t work like that. You cannot know until runtime if the method you called or the field you are trying to touch exists or not. Again type hints help a lot with this but that doesn’t change how the language actually operates.



  • So the big important part of git is that it’s a collection of commits. A branch is just a labeled commit and each commit is a list of what changed from the parent. Rebasing (the most confusing one for people) is when you fiddle with a commit from underneath yourself. Or in even more simple terms editing a parent commit. Rebasing is extremely powerful but most useful for when you notice a bug you wrote a couple commits ago. Fixing such issues via rebase (or !fixup commits you auto squash at the end) keeps your history clean. It’s as though you never wrote the bug. The other thing you do a lot with rebasing is moving your branch up in the history cause somebody updated the remote.



  • Um what? I didn’t like hide extra meaning in what I said. High quality code doesn’t imply all that extra shit you added. It’s code that’s easy to read and modify. Typically this just means you name stuff well and document things that aren’t obvious. Usually my docs explain why something exists since thinking it’s unnecessary cause you don’t remember what the original problem was a common occurrence before I started doing so.

    Is high quality code ran through a formatter? I’d hope so yeah. There should be a consistent code style across the entire project. Doesn’t matter what it it long as it’s consistent.

    100% code coverage is meaningless and as such a pointless metric. Also 100% coverage is explicitly tied to the implimentaion as all code paths have to be reached which is obviously not a good idea (tests have to change when the implimentaion changes as you’re testing the implimentaion not the api).

    Really a lot of this is just meaningless buzz words as an attempt at some sort of gotcha. Really don’t understand how you even interpreted a statement so simple in this way.







  • I’d probably say it depends but I’m no Rust expert and I have no direct experience with C (though quite familiar with C++).

    Basically I’d expect writing C to be easy, but not safe. IE you can quickly and easily write C that compiles but has runtime issues. Rust for the most part will catch everything but logic issues during/before compilation meaning once the program runs you’ll have very high confidence in it’s runtime behavior leading to time spent “fighting the compiler” instead of figuring out wtf is going wrong at runtime.


  • What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using std::unique_ptr. In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block