Comments by "p11" (@porky1118) on "Modern Software Engineering" channel.

  1. Professional programmer: Just does what the boss tells him to because getting money for it and manages to get out some product that somehow works Hobbyist: Does what he wants to do and makes everything in the corret way, but never gets to a releasable state
    12
  2. Also when working alone, branching is sometimes useful. I've already done it a few times.
    9
  3. I agree about your opinion of feature branching, but not in all cases. Basically two cases: - interns or new employees, who I don't fully trust yet, especially when they touch important pieces of code, which will probably break everything for everyone (also addressed in the video) - experimental features, until I'm sure, it will make it in
    6
  4. I also try to make my functions/methods as short as possible, but sometimes it might be better to write longer methods for redability. It's not a good thing if you always have to look up some method, which is just used in this one method and does not even make sense in a different context, and then just go back to the original method.
    5
  5. In general I'd agree, but in some cases it still seems useful to branch to me. Especially when doing some more experimental stuff, where you don't know, if you even want to add this change. But if you already know, you're going to merge this branch/feature sooner or later, it's always better to merge it now. It's much worse, when others already depend on a feature, which often changes, than when you are not able to merge this feature anymore. And you will always be able to merge your feature in most cases.
    4
  6. If you haven't compiled your project on a normal work day at least once, something is already wrong anyway, I'd guess.
    4
  7. I think, you only go faster by adding people, if you are able to separate tasks. For example, when I use some actively maintained library, I can use the progress made in that library without slowing down my own project, as long as there are no breaking changes.
    3
  8. I'm happy with gedit :) I'm using it since I started real programming on Linux. I even enabled word completion about a year ago. At work I use an IDE, but the only features I really use are auto completion and smart renaming. But often the IDE does just it's own thing and not what I want. For example the auto completion sometimes autocompletes without me explicitly selecting an option.
    3
  9. Sometimes, when a function is very general and will most likely not need module specific changes, it would make sense to share it between multiple modules.
    3
  10.  @zerettino  No, general is not technical. It means it's not special purpose. It has many use cases. It can be used in many circumstances. If you recognize some pattern in many of your modules, which could be generalized, and will still work if the modules change, it makes sense to put them into a module used by both. Even if it will cause a lot of coupling, that's not a huge problem. You can still refactor by just copying the affected function(s). So it shouldn't be too bad.
    3
  11. 4:23 I don't fully agree about the business. I wouldn't say, it's the job of the programmer or the business alone, but the programmer has to find out by talking to the customers while making suggestions and clarifying, what would be possible. Else half of the code will have to be rewritten because the customer doesn't like it.
    2
  12. I don't really get these complicated ways to design software anyway. Often you just need common sense. If you know, what you want to do, just do it. Try to use the simple method instead of the difficult one. Ensure extensibility in case you might need to extend it later. If it doesn't work as expected, try to find a different solution.
    2
  13. I think, there is still potetntial for a general purpose programming language having more influences from natural language, but not how the old approaches worked. The old programming language, which tried to make programming languages more like natural languages, did it, by translating function calls and macros to a limited set of common phrases, often making it less flexible and clear. I think, SQL is a good example, even if not a general purpose language. I would rather try to add features of natural language into programming languages. The most important feature of natural languages, which has not been implemented in any programming language, is a way to nest complex phrases without the need of explicit brackets (might be words, which act like brackets). In natural language, every word has some implicit relation. An adjective (A) always relates to the next object, which might consist of multiple words. In some languages a verb (V) at the end of a sentence or subsentence ends it. And relative pronouns (R) start a new subsentence. And Nouns (N) represent simple objects. So lets assume, we have a sentence of this structure: N1 A1 N2 R1 A2 A3 N3 N4 V1 V2 By strictly applying the rules (the description would have to be more accurate, but you should get the point), the nesting (restructured, so the verbs are written like function calls) would be something like this: V2(N1, A1(N2), V2(R1, A2(A3(N3)), N4) Even if it's not english grammer, I can try to insert some english words: English: I like the blue boat, which swims from the great island fast. Structure: I blue boat which from great island fast swim like. Nesting: Like(I, blue(boat), swim(which, from(great(island)), fast) (I know, "fast" is not a noun, and "from" is not an adjective, but it's difficult to have complex sentences, which use a structure like this and make sense.) So how would I use this in a programming languare? I'd add about three kinds of words, one which opens a bracket (like R), one which closes a bracket (like V) and one, which does none of it or both (like N or A). Maybe more. And everything you define will belong to one of these word kind.
    2
  14. 9:15 I don't think, it's in general a good idea to remove file interactions from unit tests. If it's just short strings or a few lines, sure. But if I really need to read in larger data formats, I don't want to add them into my code, but rather have them in separate files. Else I might even mess up the format, I want to parse (for example when the parsed format and the language I use both support strings surrounded by quotes and escape characters, I can't just write the content of a file down). I'd prefer to have them in real files. Maybe they could even inlined into the file at compile time and not really be read at runtime, but I don't think, this would make such a huge difference. Besides I'm not sure if writing a file system abstaction, which can be used everywhere, where a normal file can be used, will not cause other problems and make some of the code far more complicated and maybe even less performant. Java is probably an exception, where this works well, and only, because the performance reducing features are activated by default (in this case virtual method inheritance).
    2
  15.  @LarryRix  I didn't talk about function names not making sense in a different context, but the function itself being so specific, it would only be used in the one place anyway. I don't get, what the rest is about. I didn't even mention inheritance.
    2
  16. Isn't it a good workflow to merge develop into your feature branch at least once a day? It's similar to CI, but other people won't be disrupted by having to relearn changes of an unfinished feature. For example, I rename a method and add a few similar methods and then remove some, I don't want to be used, after I'm sure, which are the best methods. If I do CI, everyone has to learn the new methods, if they need one of them, and maybe they use one, I want to remove later, but can't anymore because it alreaty has been used. So I just merge the develop every few hours, so I see, nothing breaks, and when my feature is finished, I merge it to develop.
    2
  17. What I dislike about most OO languges: # No way to define simple functions There might be static methods, but they still have to belong to a specific class, which often does not make sense. In such cases, I "misuse" classes as modules, but it's often a lot of boiler plate code in this case (`public static`). # To which object does a method belong? Or I know, it should be a method, but don't know, of which of the objects. There are many posibilities, but none of them seems preferable. As long as I don't need dispatch, functions are often the way to go. Else it's pretty clear unless I need multiple dispatch, which also doesn't exist in most OO langugaes. # Being able to overwrite any method I think, methods should never be able to be overwritten in general. There's one exception: Default methods. Some method of an abstract class, which is explicitly meant to be overwritten. (any virtual method in an abstract class) And there could be empty method definitions, which can be defined in a child class (empty virtual methods). And they can only be overwritten once by an inheriting class. If you need to overwrite something twice, something is wrong with your code. Instead of overwriting methods, I like the idea of methods, which extend the behavior of the parent but without changing it (see method combinations), but most of the time, this is too complicated. In cases, you want to extend behavior multiple times, it's probably the best to add a new virtual methods in child objects. This way it's not allowed to accidently forget to call the parent method, which often seems like boilerplate anyway.
    2
  18. So "Agile" is just the way, most/good programmers already work, but in order to let the programmers work, how they work most efficiently, in more traditional business, you need a new term to convince them. Did I get that right?
    2
  19. 14:00 I don't like both. I'd like to write something like this: someCollection.map(fn (c) c.size).sum()
    1
  20. I kind of hate these acronyms for programming principles. I always think "Oh, another weird business technique, I'm not interested in". And most of the time, when I find out, what one means, it's either common stuff, I do anyway, because not doing it that way would be stupid (for example DRY), or it does not apply to the languages I'm using (like SOLID mostly).
    1
  21. When you write your code as fast as possible, and then fix bugs most of the time until all the obvious bugs are gone, I guess.
    1
  22. 8:00 That's basically what I do with my projects. If I see some functionality, that might be useful for other programs as well, or when I need it for another program and don't want to rewrite it, I create a new repo, add this submodule of the existing program into that repo and let the other program use it. When I find a bug in my new repo or have ideas for improvement, or if I need to extend it to work with one of my programs depending on it, I have to upgrade the repo, but not all programs, which depend on it. Sometimes I do, sometimes I don't, most of the time I at least plan to upgrade to a newer version some day. Especially when using Rust, it's easy to have different programs using different versions of the same library.
    1
  23. I think, a good programming language should just support every paridigm, when I want. So I could have more restrictions, if I say so, but also have direct access to memory, when I want to. And I like how rust does it most of the time: By default, you are more restricted, but you can relax restrictions explicitly (mut, unsafe).
    1
  24. Before I watch the video: I also recognized, that too much branching is rather worse than beneficial. It should only be done for complex features, which might effect everyones work in a negative way. Like some major rework of an important feature. I like to let interns work on their own branches, so they don't fear messing up everything, but most of the time, I just merge everything as it is and fix problems later anyway. Only if it's something very bad, I would not merge it. But the worst thing, that happened so far, were some commits of unintended data, which weren't that bad, so I didn't merge everything, but cherry-picked a few commits.
    1
  25. System 1: Do you want to prove this wrong to me by giving be food? System 2: I don't know, I don't care.
    1
  26. I will take about two hours, maybe faster, if I'm able to focus, but if I realize, I have to rewrite some component, which I wanted to rewrite anyway, it will last at least one day longer, but if my approach of the rewrite does not work at the first try, it might take even longer, maybe it relies on other components, which need some refactor as well. And when I'm done, there might be a few bugs, which could take less than a hour to find, but also one or two days, depending on my mental condition and if I my guesses, where the bugs might come from, are right, or if I follow the wrong track for some hours...
    1
  27. 11:00 I often even do big refactors or just rewrite classes instead of looking for bugs, when they are not obvious and difficult to find because it's faster and in the end, I understand better, what's going on, because I removed all the old code, which does not, what I currently want, etc.
    1
  28. You should write methods and functions in a functional style, but I'm not such a fan of inheritance, except of multiple inheritance of abtract classes maybe. But overriding functionality of some working class is against my values. I only use it, when I don't see a good alternative, because I have to use a language, which does not provide any good alternatives. I like rust traits instead, but interfaces (like in go) or c++ concepts, should be a good alternative, too.
    1
  29. 3:50 Only three of the lines are repeated. The last one is always different. It might be useful to only put the three same lines into a new function.
    1
  30. When working with Unity, we never had code ownership. We still have Scene ownership, though. Since merging scenes is only possible in special situations, like when values are changed. But not when something in the hierarchy is restructured.
    1
  31. How can this be applied to gamedev? Most things can't be independently deployable. Especially things, you would put into a library, like a physics or render engine, or more important your math stuff. But you could put the rendering and the physics of a specific game into different microservices for example. Not sure, if that counts. But both could be independantly deployable. You could test the game rendering by sending the game state to it, where which object moves and how they change, which objects get destroyed or created, if a new scene is loaded, etc. You could even use it for different games, which use different physics or no physics at all, as long as the rendered objects stay the same. Or you could test the game physics by using a very minimalistic renderer, or just outputting the expected positions. You could run the game with many different renderers, maybe some minimalistic 2D one or some realistic 3D one, or some surreal style. That's basically how I tried to make some game I made less coupled. But I'm not really happy with it. They use the same base code, some shared structs which are used by both services. But both services include most of the same structs, only cleaned up. For example balls in the renderer don't contain the speed, and balls in the physics don't contain the color. So it's kind of code duplication. I created a library for both "services", so I still have to add some code to really make it run. I basically just have to define how the communication works. I can use both libraries and just move data around inside the application to create a standalone. Or I use only one of these libraries to write to and read from a tcp stream and create a client and server this way. I like the basic design, but I'm not happy with the specifics. What I also can think of is packing menus and the real game or each different part of the game into a single application, and then add a meta application, which just selects the next application.
    1
  32.  @jangohemmes352  No, I even split repos. So you don't think, microservices can be applied to gamedev, right?
    1
  33. Programming and software architecture is the same in my opinion. Most of programming is to think about how to organize the types, methods, classes, traits or whatever.
    1
  34. I only comment: * functions/types I defined, if the name is not obvious (or if I use them to generate documentation, also the obvious ones) * difficult segments, mostly math, which I often forget myself * things that seem like some mistake, but actually have to be this way ("don't remove this assignment. It does not just redefine an existing variable, but accessing the original variable implicitly invokes a non-performant calculation")
    1
  35. I don't think, I would let the one, who makes the best food, win an argument. On the one hand, noone can bring better food, than I eat at home, especially what my grandma did, and ot the other hand, I don't believe my grandma much more than other people because of that.
    1
  36. So since Rust supports polymorphism, it would be OO.
    1
  37. I also just ask, when I have a question. Often it's just faster than trying to remember myself.
    1
  38. 7:25 That's why I don't like using game engines. I can get started easily, but I have to learn a lot of features, most of them more complex than they need to be for my use case, and not as flexible. I prefer the idea of reusable libraries. I can easily remove one library and use a different one instead.
    1
  39.  @hannessteffenhagen61  Unity doesn't seem like it's aimed at professionals. The benefit is, you can also get something done yourself, if you don't know that much about the project. And even in Engines, you still need a lot of programming for the actual game logic. You just don't need to know how to do some basic things like math, physics, rendering, audio, asset loading. But when not using engines, you also just need to use some libraries, which already exist. You just have to decide for some, and maybe they don't work together well because the physics lib uses different vector types than the rendering lib, but getting something almost as good as an engine shouldn't be too difficult.
    1
  40. 6:19: What are function points? The number of functions after compiliation? I guess, c++ or something similar, because of templates (generics), which get expanded for every function/method.
    1
  41. Oh, looks like small numbers of functions are up. Then I'd expect some language, where you don't have multiple functions/methods/constructors for similar behavior, but keyword arguments, probably you would not write constructors at all to create objects/structs, nor would you have any generics, which might create multiple versions of a function.
    1
  42. I'm kind of the leader in my team, since I'm the only employed programmer, and everyone else is an intern. I normally let them do, what they want. When I see, they are doing something stupid, I'll tell them, how I would do it, or how they could improve the code. If they don't fix it, I'll probably fix it myself some time later, at least when I have to work with the code. It doesn't make too much sense to force a programming style onto them, when they will just stay for a few months. It will just slow them down.
    1
  43. I might have heard the term "DevOps", but I don't know, what it means and also never used it.
    1
  44.  @timothyblazer1749  In most VCS merges are more complicated than they need to be. Git for example always needs a merge commit if you merge something which is not just a fast forward. In Pijul, which is still in development, you only need a merge commit if two changes change the same line of the same file. And merge conflicts should appear less often anyway.
    1
  45. But that's more of a problem when doing CI. When everyone is pushing on the same branch, up to every second commit is a merge.
    1
  46. 4:25 You could commit often, but not push to the branch, which most people are using.
    1
  47. Isn't it a good workflow to merge develop into your feature branch at least once a day? It's similar to CI, but other people won't be disrupted by having to relearn changes of an unfinished feature. For example, I rename a method and add a few similar methods and then remove some, I don't want to be used, after I'm sure, which are the best methods. If I do CI, everyone has to learn the new methods, if they need one of them, and maybe they use one, I want to remove later, but can't anymore because it alreaty has been used. So I just merge the develop every few hours, so I see, nothing breaks, and when my feature is finished, I merge it to develop.
    1
  48. I agree about many parameters. You should pack multiple related parameters into structs. For example a vector instead of (int x, int y), especially if you have multiple of them. Same for structs/classes with many fields: If some belong together, pack them into a substruct, especially if you might need multiple of them.
    1
  49. In Games and Graphics programming, especially when using engines like Unity, I'm not sure if writing tests would be that useful. If you can extract a subsystem, which works by itself, writing tests seems like a good idea, but else they won't help that much. The best "test" is playing the game.
    1
  50. 7:42 I almost don't type, when programming. I can type pretty fast, I guess, but also not too that fast. Most of the time, I have to rearrange code, which already exists, anyway. So efficiently using copy/paste is probably more important than fast typing. Or putting code, which you often reuse into a function, so you don't have to write/copy that much.
    1