The best solution is one that sounds impressive, does little, has no risk, and quietly slushes money off to friends.
It sounds impressive to get votes. It does little so you can 'solve' the same problem again next year (see for example, the medicare doc fix). It has no risk, because, you know, that could make me look bad. Anything with risk needs to be rethought.
That won't happen. A company that writes security vulnerabilities will continue to write them, thus providing an endless supply. Until something changes within the company, there will be a bountiful harvest for both black and white hat.
I would do it by making a function something like, newGameStateScreen() which is a function of the old screen, and the current state (maybe even the old state). That part is fine enough.
Then I would cheat and optimize it to actually update in place. Conceptually it would still be functional, but every useful functional program ever written mutates state.
But if you have FP, then you have repeatability. Given a particular game state, combined with a given input, you can know what the next game state will be, every time. It's testable, provable, and helps you make sure that every possibility is covered.
The irony is that you don't realize you are stereotyping people in the same way that you dislike when they do it. Learn who people are, don't attack strawmen. That's what got us into this problem in the first place.
The black market will always pay better. If companies increase their offers, then the black market will increase them even higher. Although as the prices rise, the number of buyers on the black market will decrease.
Especially since the things that Rust does well (avoiding memory leaks and overflows) have absolutely nothing to do with the errors mentioned in the summary (SQL injection and XSS). Your code can be absolutely leak free and still have an SQL injection, it's a problem of the API not the language.
The radio is one of the things I look at when choosing a car, and I have decided not to buy a car based on the features and functionality provided by the radio.
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
I feel like you're trolling, but if the sound system requires you to have a particular way of mounting your NFS, then yes, that is a horrid, sucky design, and you know it.
Most Linux users don't have a strong opinion on systemd either way, because the system boots up reliably without systemd, and it also boots up reliably with systemd. Overall it's barely noticeable and doesn't matter (right now, anyway) for most users.
There are people who write startup scripts for Linux, and they tend to have a stronger opinion, because it affects them more directly. Some really like systemd, some really don't. Some (like Patrick Volkerding) are fairly neutral about the whole thing but see no pressing need to switch.
Then there are people who are system designers, who are ok with systemd as an init system, but see it as horrid when it's a platform for building an entire OS. As long as it stays as an init program, it's fine because it can be swapped out easily. But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.
If you ask a C# programmer what language he uses when he programs for fun at home, he will say, "I don't program for fun." It won't be C#.
(The above of course is a generalization, and if you happen to be a C# programmer who programs in C# for fun, I don't understand you, but I don't judge you either).
Now, if you don't mean neural networks when you say AI, then what the heck do you mean when you say AI?
I don't know about the person you are replying to, but I get really annoyed that when scientists say "AI" they usually mean weak AI, and when newspapers hear it they usually think strong AI. We're not anywhere close to solving the strong AI problem, but some of the algorithms we've come up with along the way are really, really cool.
Slashdot Mirror
The problem is you don't have a winter to kill off the gorillas. Need some global cooling for a bit.
The best solution is one that sounds impressive, does little, has no risk, and quietly slushes money off to friends.
It sounds impressive to get votes. It does little so you can 'solve' the same problem again next year (see for example, the medicare doc fix). It has no risk, because, you know, that could make me look bad. Anything with risk needs to be rethought.
That won't happen. A company that writes security vulnerabilities will continue to write them, thus providing an endless supply. Until something changes within the company, there will be a bountiful harvest for both black and white hat.
I would do it by making a function something like, newGameStateScreen() which is a function of the old screen, and the current state (maybe even the old state). That part is fine enough.
Then I would cheat and optimize it to actually update in place. Conceptually it would still be functional, but every useful functional program ever written mutates state.
But if you have FP, then you have repeatability. Given a particular game state, combined with a given input, you can know what the next game state will be, every time. It's testable, provable, and helps you make sure that every possibility is covered.
That's a good description of that scene. Of course I've seen it, but I never quite thought of it in those terms. Your words capture it well.
The irony is that you don't realize you are stereotyping people in the same way that you dislike when they do it. Learn who people are, don't attack strawmen. That's what got us into this problem in the first place.
The black market will always pay better. If companies increase their offers, then the black market will increase them even higher. Although as the prices rise, the number of buyers on the black market will decrease.
I don't get it why some many developers WON'T use the real documentation
Because reading documentation is a skill many of them have not developed yet.
Especially since the things that Rust does well (avoiding memory leaks and overflows) have absolutely nothing to do with the errors mentioned in the summary (SQL injection and XSS). Your code can be absolutely leak free and still have an SQL injection, it's a problem of the API not the language.
All those stereos integrate with the CANBUS these days (which is really stupid to do from a security standpoint, BTW),
Why would you want to do that? What benefit do you get?
This calculate captures your opinion fairly well. Not all aspects of science are equally solid.
You have not addressed the point at all. Hot plugging doesn't mean you should create a bad design.
Do you still drive a car from the 90s? You would lose a lot of functionality in a modern car by attempting to replace the radio system.
haha yeah, actually. I should get my knowledge updated.
Have you been to any car dealers in the last 10 years?
No actually haha. I should update my knowledge.
It's all fun and games until your physical car decides to stop for hot coffee.
The radio is one of the things I look at when choosing a car, and I have decided not to buy a car based on the features and functionality provided by the radio.
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
I feel like you're trolling, but if the sound system requires you to have a particular way of mounting your NFS, then yes, that is a horrid, sucky design, and you know it.
Most Linux users don't have a strong opinion on systemd either way, because the system boots up reliably without systemd, and it also boots up reliably with systemd. Overall it's barely noticeable and doesn't matter (right now, anyway) for most users.
There are people who write startup scripts for Linux, and they tend to have a stronger opinion, because it affects them more directly. Some really like systemd, some really don't. Some (like Patrick Volkerding) are fairly neutral about the whole thing but see no pressing need to switch.
Then there are people who are system designers, who are ok with systemd as an init system, but see it as horrid when it's a platform for building an entire OS. As long as it stays as an init program, it's fine because it can be swapped out easily. But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.
If you ask a C# programmer what language he uses when he programs for fun at home, he will say, "I don't program for fun." It won't be C#.
(The above of course is a generalization, and if you happen to be a C# programmer who programs in C# for fun, I don't understand you, but I don't judge you either).
The irony is that you are the one promoting fake science with your post. The erosion here isn't caused by AGW. If any, just a very small percent.
But most likely you will ignore that fact, and continue on with your angry rant.
Nice data-filled comment, thanks.
I'll be honest, I wish I understood this, but I don't.
Wine doesn't work well on all laptops, whereas the old classic mode still worked fine.
Yes, I know US median household income has been stagnant since the 1970s
And it isn't, if you look at total compensation per hour.
Now, if you don't mean neural networks when you say AI, then what the heck do you mean when you say AI?
I don't know about the person you are replying to, but I get really annoyed that when scientists say "AI" they usually mean weak AI, and when newspapers hear it they usually think strong AI. We're not anywhere close to solving the strong AI problem, but some of the algorithms we've come up with along the way are really, really cool.