Is the pool running dry or are they simply not putting enough water in or allowing enough people through the gate? I've seen the job ads. Must have five years. Must have x, y, z. For a junior position. Unrealistic.
Same person can get a web job elsewhere with much less nonsense. So off they go.
Like a lot of things in IT these shortages are nonsense. They are lobbying for visa relaxation or similar so they can pay less.
Right now I'm playing with simulated weather systems using an automata for each grid location at an effective resolution of a square km. I'm getting predictive real-world accuracy within around 10 degrees C with a range of 2 days. Very rough. Takes a long time to simulate a globe which I've found is really important to do. A limited region is usually not as useful.
Its an interesting field. But its seems not so easy to get the real methods used by the bigger models.
I'd connect it to social media and have it write comments on random posts. For fun perhaps it would reply mostly about AGI topics but also general mathematical topics as well. This would be a simple way of exercising its ability to synthesise language usage beyond the expected collection of word chains usually employed by ML techniques which are often tricks rather than real learning.
Upvotes and replies would serve as metrics on how well the AGI is progressing.
Sounds like you forgot why you started AND/OR haven't broken the next step into something small enough you can continue/resume. That sense of why clarifies the drive to move forwards. What's blocking the next step? Too big a jump? Something in the way that you need to step around?
So we learn the real answer is 256^1024 according to a limited concept of combinations. Its not so good when a mathematician makes such a rudimentary mistake using high school or secondary school mathematics but that's another conversation.
I'm not even sure you can accurately tell me all the uses for a 1 bit value let alone a kilobyte. The number of uses is independent of the number of combinations. If your answer is two you're way off.
Since when does knowing how many combination of states determine what you can do with something? Just because something has 256 states doesn't mean there are 256 different uses for it. There might be 124 uses for binary 00000000. But you won't know that by calculating 2^8.
There might be only three uses for 10100111. One of them makes the world feel pleasant, another melts your face off and another releases three male rabbits into the same cage. But I doubt there's only three. There's likely millions of potential uses for just that pattern alone. How exactly would you calculate how many? Accurately? I'm unconvinced.
The real issue here is lack of imagination. Placing limits where none need exist as well as failing to see possibilities without considering the vastness already present. 2^8 doesn't even begin to cover the number of uses for a single byte.
Rephrased differently: how many uses for a hammer? Can you know only by analysing its orientation? I doubt it.
Rephrased differently (again): feeding a particular combination into different machines will generate a different result. Can you predict the number of results from a given combination without knowing how many machines could process it? I doubt it. The question itself has too many unknowns in it.
I'll leave it there. I respectfully agree to disagree. What to you looks like a strawman is for us a signpost towards identifying a module that needs linting and code review. Code that cannot handle that typedef change? Yeah it needs review. What other issues are hiding in there? Oh wait what have they been doing with the preprocessor?
The codebases we work on are from the 1980s. They sorely need to be dragged kicking and screaming if necessary to later standards. So many warts. People abused the preprocessor like it was normal and expected.
The semantic change isn’t as big as you'd expect. Even as it is in fact a semantic change. But I sense significant gatekeeping as well to hold back the tide.
Sounds like: We've always done it this way. Often rephrased as: Its not possible to write a script to fix this. We can't have automated tests. There's no way we can find all the places this is likely to be used. There's no way to do this at all because insert-authority-figure's-opinion. Oh no! But really its all historical rather than a real issue.
Its just a code smell. There are likely other bugs hiding around the code. Business logic issues as well. Overall its a story of generally poorly written and ambiguous code. So... Perhaps fix it?
If you can't fix it then a compiler option would do it.
Wrapping structs in typedefs like this should be a distant and quaint memory by now. C'mon guys its 2022. Why hasn't some standard gotten rid of this requirement for typedefs around structs?
Deprecate this requirement already and make it an option.
Gcc --stupid-typedef-required
Edit: or stated in another way, please describe the good reason(s) for having typedef struct {} Foo in C. Do it in terms of justifying the extra typing / extra steps. I'd really like to know. This is extra code and one more thing to test and confirm. Don't reference history or "its just how its always been done" - that to me is an admisson that it needs to go into an option. Also you'll need to explain why its bad that C++ doesn't require this. I'd also like to see as part of this rebuttal a formal statement that C++ got it completely wrong.
So: Why in C do we require the extra steps just so we can get rid of the struct keyword having to be plastered everywhere?
Personally I think the typedef struct pattern is kept purely for historical reasons and is no longer necessary. It obscures the code rather than clarifies it. There are much better reasons for using typedef but getting rid of "struct" prefixes everywhere isn’t one of them.
IMHO: in order to say yes you are usually saying at least one or more no's. Otherwise the lack of those other no's will eat you alive.
Oddly enough, though, all those things you listed are possible if you reduce the scope and scale of the projects. Its a matter of saying no to massive undertakings and be pragmatic about it.
A "programming language" doesn't have to compete with C or rust or something equally huge. It could be a little DSL instead. "Cryptography" could be a key store or other simple encryption tool. The "sci-fi epic" could be a novella or even a short story.
But at the same time, even those undertakings might still be too large a bite to take out of your weeks.
So, as you say, prioritise and accept your own limitations.
Says a lot about hiring practices and systematic biases. Even small biases creep up and accumulate. I wonder if women are more likeky to hire tall men over short men? What about male hiring of males, does that have a bias?