There is no generic answer to this question. And that's why also there is no generic answer to the question "should I use a recursive function". As a programmer that's your responsibility to use the right tool for the job.
Unless you write code directly in assembly, the stack is far from what you "the hardware stack".
A recursive algorithm use the function call stack and the translation of that stack to the CPU stack is dependent on the compiler or the runtime environment. The limits of that stack is also dependent on the runtime environment, and the program may even have control of the size of that stack at runtime to raise the limits if necessary. The OS may also give control to the OS user on the size of that stack (man setrlimit) outside of your program (the program exhausts the stack? run again with a higher "ulimit -s").
Computer resources (not just the stack) are always limited anyway. Using one algorithm or another is always a tradeoff on which resource you may exhaust first. The stack size is not always the first exhausted resource for a recursive algorithm. So "Never use recursion" should not be general rule.
Unrolling a recursive algorithm to loops also has a cost: the code is often longer (in lines of code) and more complex (because you have to maintain the state that is handled in the stack in the recursive case), so may be harder to maintain and may have more bugs. You'll often have to write unit tests that compare the correctness of the unrolled implementation against the (simpler) recursive one.
In some countries, when you leave a job you get a statement of income to date for the tax year, which you then give to your next employer so they can set up the right deductions on your salary payments.
And so? How will they prove that they made you an offer based on a false oral statement from you? Because they recorded the interview? I don't think that would be legal. In any case that would be little ground for a ligitation. If this subject comes in a court, you probably have a much bigger problem in your relationship with that employer.
> The really relevant stuff doesn't need a url anyway, because they already know the name of the software.
The other obscure stuff is also helpful to the recruiter. At least to eleminate you if your side projects are just shit. If your side project made in your free, unlimited time is just badly coded, with poor commit messages, what can a recruiter expect from you code quality on a time-constrained project?
Promises are a bet on the future. But the future may not happen as envisioned at the time the promise was made. Would it be fair to punish people for not correctly predicting the future? Do you really want any promise to be applied even if it does not anymore apply to the context it was envisioned?
Citizen voting has at least two requirements: - the ballot of a voter is secret - voters must vote only once, so voters must be authenticated and vote must be recorded.
So far I am not aware of a blockchain based system that garantees both.
I notice you used a comma in your sentence because it has a meaning and add information to the sentence in addition to just letters. You could have used bold and italics. Sigils in Perl have the same purpose.
1. Scan all traffic at edges of the network in Russia. 2a. If you are able to decrypt it (well, if ever a implementable definition of "decrypt" is published), let it pass. 2b. If not, block it.
All the traffic that remains is decryptable. So this is achiveable, as long as you accept as a compromise to block so much traffic that not much usage of the Internet remains.
That long notice time is effective only after a trial period (of the same duration, so usually 3 months, but can be extended once by either party) during which you can leave without notice.
3 months is the standard notice time for a developer (and for most qualified jobs) in France. This is written in your contract when you get a job. This is both ways: when you leave or when you are fired.
So leaving without notice time (or with a shorter time) is something you have to negociate.
8 months ago, when we rebuilt the previous version of our platform that was insanely in PHP (with an insane level of intricated web services) that had poor performance, we wisely choose Go. Go is compiled. Go has strict type checking. Go has built-in support for writing unit tests.
And Go's support for concurrency is far much better than node.js (which still runs on a single CPU).
All the McDonald's and Quick restaurants in my area in France have already implemented that. There is much more ordering machines than ordering counter with humans.
And I have to admit that the customer experience is much better because this is much less stressful at least at crowded hours: - all the available options are visible in front of you, along with prices (instead of having to search for them displayed far away or to hear about them in a noisy environment) - you can take your time when interacting with a machine - all machines are equal
- no slow rookie cashier
- no crazy cashier who speaks too fast And we can even have our order directly delivered at our table.
Slashdot Mirror
Just change the default settings.
There is no generic answer to this question. And that's why also there is no generic answer to the question "should I use a recursive function".
As a programmer that's your responsibility to use the right tool for the job.
Unless you write code directly in assembly, the stack is far from what you "the hardware stack".
A recursive algorithm use the function call stack and the translation of that stack to the CPU stack is dependent on the compiler or the runtime environment. The limits of that stack is also dependent on the runtime environment, and the program may even have control of the size of that stack at runtime to raise the limits if necessary. The OS may also give control to the OS user on the size of that stack (man setrlimit) outside of your program (the program exhausts the stack? run again with a higher "ulimit -s").
Computer resources (not just the stack) are always limited anyway. Using one algorithm or another is always a tradeoff on which resource you may exhaust first. The stack size is not always the first exhausted resource for a recursive algorithm. So "Never use recursion" should not be general rule.
Unrolling a recursive algorithm to loops also has a cost: the code is often longer (in lines of code) and more complex (because you have to maintain the state that is handled in the stack in the recursive case), so may be harder to maintain and may have more bugs. You'll often have to write unit tests that compare the correctness of the unrolled implementation against the (simpler) recursive one.
So "no recursion" is a strict rule for your environment.
That's doesn't make it a general rule for programming.
And so? How will they prove that they made you an offer based on a false oral statement from you? Because they recorded the interview? I don't think that would be legal.
In any case that would be little ground for a ligitation. If this subject comes in a court, you probably have a much bigger problem in your relationship with that employer.
> The really relevant stuff doesn't need a url anyway, because they already know the name of the software.
The other obscure stuff is also helpful to the recruiter. At least to eleminate you if your side projects are just shit. If your side project made in your free, unlimited time is just badly coded, with poor commit messages, what can a recruiter expect from you code quality on a time-constrained project?
> So programmers would be the only people who have needs? Or in other words, anybody who has a need had better become a programmer?
No. Just people who want sotfware "free as in beer" (not counting time and tools).
Promises are a bet on the future. But the future may not happen as envisioned at the time the promise was made.
Would it be fair to punish people for not correctly predicting the future?
Do you really want any promise to be applied even if it does not anymore apply to the context it was envisioned?
Citizen voting has at least two requirements:
- the ballot of a voter is secret
- voters must vote only once, so voters must be authenticated and vote must be recorded.
So far I am not aware of a blockchain based system that garantees both.
You can always cleanup that Perl 5 code using a module such as Path::Tiny:
use Path::Tiny;
my $data = path('file.txt')->slurp;
I notice you used a comma in your sentence because it has a meaning and add information to the sentence in addition to just letters. You could have used bold and italics. Sigils in Perl have the same purpose.
Just one counter example: Lisbon, Portugal is not on the same timezone as Paris, France. WET/WEST vs EET/EST.
We have the key. The algorithm to use it is left as an exercise to the reader.
1. Scan all traffic at edges of the network in Russia.
2a. If you are able to decrypt it (well, if ever a implementable definition of "decrypt" is published), let it pass.
2b. If not, block it.
All the traffic that remains is decryptable. So this is achiveable, as long as you accept as a compromise to block so much traffic that not much usage of the Internet remains.
That long notice time is effective only after a trial period (of the same duration, so usually 3 months, but can be extended once by either party) during which you can leave without notice.
Time to go back?
But if the system is like in France, they are also giving that notice time when they are firing, isn't it?
3 months is the standard notice time for a developer (and for most qualified jobs) in France. This is written in your contract when you get a job. This is both ways: when you leave or when you are fired.
So leaving without notice time (or with a shorter time) is something you have to negociate.
To be fair, all repositiories of open source libraries have this kind of issues.
8 months ago, when we rebuilt the previous version of our platform that was insanely in PHP (with an insane level of intricated web services) that had poor performance, we wisely choose Go.
Go is compiled. Go has strict type checking. Go has built-in support for writing unit tests.
And Go's support for concurrency is far much better than node.js (which still runs on a single CPU).
As anyone from the ./ crowd would have, he ate there to have the ordering kiosk experience.
All the McDonald's and Quick restaurants in my area in France have already implemented that.
There is much more ordering machines than ordering counter with humans.
And I have to admit that the customer experience is much better because this is much less stressful at least at crowded hours:
- all the available options are visible in front of you, along with prices (instead of having to search for them displayed far away or to hear about them in a noisy environment)
- you can take your time when interacting with a machine
- all machines are equal
- no slow rookie cashier
- no crazy cashier who speaks too fast
And we can even have our order directly delivered at our table.
OpenBSD (or any other OS) can't workaround backdoors in Intel/AMD hardware or firmwware.
http://mail.fsfeurope.org/pipe...
Why do you think there is free wifi in airport?
Is there any better place to spy high profile foreigners' devices than in airports?
Unfortunately, in less than 10 years, the answer to every question regarding invasive tracking technology will simply be "drone".
In a room?