Programming thread

Your guess is as good as mine. This is actually being thrown out because it's illegible and archaic. The project is to replace it with a new C++ implementation. It took me 30 minutes to find int main because I couldn't isearch-forward for it. Who ever wrote this originally must have had nuclear autism.
Is it possible it was transpiled from some other language that was trendy at the time? Maybe the code you’re seeing wasn’t written by a human in the first place.
 
Started coding in react
I made this
1622799457828.png
 
In a FSM implementation in Unity is it bad practice to have a state transition interrupt come from the context code (rather than the current state code) for a special condition state that can occur from any state? Or should each state have a condition to transition to that special state?
 
In a FSM implementation in Unity is it bad practice to have a state transition interrupt come from the context code (rather than the current state code) for a special condition state that can occur from any state? Or should each state have a condition to transition to that special state?
The answer to that is wildly context dependent. You need to go "up a level" to answer it for real.

When programming any sort of entity, you need to design it to have ONE main source of control. There should never be two "controllers" ultimately telling the game object what to do directly.

So if it's just an animation FSM, then it's usually perfectly fine to have interrupts and switch state from outside because the FSM itself is mostly a cosmetic thing that ultimately doesn't effect anything else (sans if you have events triggered by animation frames, which is a bad idea usually imo).

If it's an entitystate/AI controller, you should try and keep that as self-driven as possible. It can poll for and respond to external events and triggers, but in general, nothing else should be directly controlling what it does.
 
The answer to that is wildly context dependent. You need to go "up a level" to answer it for real.

When programming any sort of entity, you need to design it to have ONE main source of control. There should never be two "controllers" ultimately telling the game object what to do directly.

So if it's just an animation FSM, then it's usually perfectly fine to have interrupts and switch state from outside because the FSM itself is mostly a cosmetic thing that ultimately doesn't effect anything else (sans if you have events triggered by animation frames, which is a bad idea usually imo).

If it's an entitystate/AI controller, you should try and keep that as self-driven as possible. It can poll for and respond to external events and triggers, but in general, nothing else should be directly controlling what it does.
Thanks, that confirmed what I thought initially. This specific state is very brief and right now is for animation purposes only, but I'm starting to see some ways how it could be a problem in the future. May require some rewriting.
 
  • Like
Reactions: Bongocat
I know enough about coding to know that this is probably a stupid question, but I'm going to ask it anyway.

Do we have any metric on what the "average coding speed" is? I don't mean typing speed (which as most of you will know is basically unrelated except in extreme cases). The answer to that would be wildly context dependent, so obviously that complicates the answer, but I'd like to know if there's been any studies or writings on that.
 
I know enough about coding to know that this is probably a stupid question, but I'm going to ask it anyway.

Do we have any metric on what the "average coding speed" is? I don't mean typing speed (which as most of you will know is basically unrelated except in extreme cases). The answer to that would be wildly context dependent, so obviously that complicates the answer, but I'd like to know if there's been any studies or writings on that.
I don't have much to offer except this story and a high effort satire on the topic. I think it would be like trying to measure productivity by the amount of paint an artist uses.

I'd be interested in any better answers but the only way I've found to measure productivity is by qualitative assessment of the work done, the bugs that came from it, and the dividends it later paid. Even then you just miss stuff.
 
  • Like
Reactions: Marvin
Ha, I ended up reading half of the articles on that blog. Hilarious. Thanks for sharing.

But yeah, to figure out how to quantify speed of code, you have to start with figuring out how to count code. Counting code by line is one common method, but even that's not reliable since different languages, or even different coding standards in the same language, can be more or less verbose to achieve the same result.

The better thing to count is results. How many bugs did you fix? How many important new features did you add to the code base? How much faster did you make this part of the code base by refactoring it? Even this is imperfect because some bug fixes are far simpler than others, but at least it starts from the point that recognizing that the results that a piece of software can provide are more important than quantitative aspects of the code itself.
 
  • Like
Reactions: Marvin
I know enough about coding to know that this is probably a stupid question, but I'm going to ask it anyway.

Do we have any metric on what the "average coding speed" is? I don't mean typing speed (which as most of you will know is basically unrelated except in extreme cases). The answer to that would be wildly context dependent, so obviously that complicates the answer, but I'd like to know if there's been any studies or writings on that.
It doesn't matter how fast you type, what matters is whether the software at the end is correct or not. No one cares if you spent hours making a nice class with lots of setters and getters if an basic error was over looked.

This reminds me of that part in Stroustrup's CppCon2017 Teaching Modern Cpp lecture. The idea from the lecture is that you should be able to mimic the traditionally used syntaxes from other disciplines in programming to avoid errors. This relates to being productive because it's not about providing features, but providing the right features. If you know you will be doing parts of calculations in metric and other in imperial, then you want to express that in the code; you have to know what the correct implementation needs to handle before it's even written. Unless you like tenderising chicken, you need to understand what data you're working with before you can even dream of having a nice API to go with it. It's like going shopping for ingredients before you know what recipe you want; it's more efficient to decide what is needed before it's time to retrieve it. That, or in Stroustrups example's case you could just fire everyone who does not exclusively use the metric system. My sense is that there is a perception that creating very full classes and APIs is being efficient, but it's definitely not being cost efficient. I don't ever think about methods before I have the thing at least working correctly, then I can decide how best to have it called in the program.

I've tried it the other way, doing the API first, but it never works out; I end up doing everything twice which is not efficient. Once, when I'm playing (and that's really the operative work) API architect. And again, when I actually know what's needed. I know some programming languages don't allow this and need to have the API defended first. I think this is bad. How should be answered first and with-what should be answered second and never the other way around. Then again, I don't get paid to crash space junk into foreign planets, so what do I know.
 
After arguing in the matrix all day I'm looking at Rocket. I have a sense of impending doom with XenForo dropping our license and then I'll have to find some sort of solution for the forum moving forward. I could easily approach a forum with PHP8/Laravel but nobody seems to use PHP anymore and I get bullied for it. It's also just not very "performant", I guess. I wouldn't know since I don't have much experience with anything else.
 
After arguing in the matrix all day I'm looking at Rocket. I have a sense of impending doom with XenForo dropping our license and then I'll have to find some sort of solution for the forum moving forward. I could easily approach a forum with PHP8/Laravel but nobody seems to use PHP anymore and I get bullied for it. It's also just not very "performant", I guess. I wouldn't know since I don't have much experience with anything else.
Stay away from that hipster crap barely anyone uses and just use what you're familiar with and what works.
 
After arguing in the matrix all day I'm looking at Rocket. I have a sense of impending doom with XenForo dropping our license and then I'll have to find some sort of solution for the forum moving forward. I could easily approach a forum with PHP8/Laravel but nobody seems to use PHP anymore and I get bullied for it. It's also just not very "performant", I guess. I wouldn't know since I don't have much experience with anything else.
Have they actually announced an intention to drop it, or do you just suspect they're going to based us not hitting our woke quota?
 
Stay away from that hipster crap barely anyone uses and just use what you're familiar with and what works.
What does that mean? GoLang is adopted by Google, Rocket/Ruby is adopted by Mozilla + all trannies, and PHP was abandoned by its only major sponsor (Facebook, which inhoused HHVM)

Have they actually announced an intention to drop it, or do you just suspect they're going to based us not hitting our woke quota?
I said "sense of impending doom", not "they said they were going to"
 
Would Xenforo really bother pulling our license? I believe you're allowed to keep running the software even if your license expires (or is pulled, presumably), you just don't get support and new patches.

And I bet you could get the patches from a concerned passer-by.
 
Would Xenforo really bother pulling our license? I believe you're allowed to keep running the software even if your license expires (or is pulled, presumably), you just don't get support and new patches.

And I bet you could get the patches from a concerned passer-by.
XenForo Limited reserves the right to revoke Your License to use the Software should any of the terms of this Agreement be violated. In the event that We revoke Your License for a violation of this Agreement, no refund will be granted.
 
  • Horrifying
Reactions: Strange Looking Dog
XenForo Limited reserves the right to revoke Your License to use the Software should any of the terms of this Agreement be violated. In the event that We revoke Your License for a violation of this Agreement, no refund will be granted.
Yeah, looks like the support expiration is different from a license termination. Never mind :stupid:
 
I could easily approach a forum with PHP8/Laravel but nobody seems to use PHP anymore and I get bullied for it. It's also just not very "performant", I guess. I wouldn't know since I don't have much experience with anything else.
Laravel is fine and used as the backend for lots of apps. The main change over the last few years is that the frontend is usually decoupled from it and has some kind of JS framework executing in the browser making requests to an API running Laravel (or some other framework).
 
Back