It's not actually over-assigning. The spots get used regularly if you
count time in days rather than minutes. Basically, the chance that a
handicapped spot is used at least once (by someone deserving) in a day
is pretty high for a busy place, but the chance that a random person
will be in the area just when it happens to get used is very low.
To resolve the paradox, ask the question: Is a (regular) spot going to be used today? Is a (handicapped) spot going to be used today? In both cases the answer is about the same, and that means there's no overassignment at all, it's actually efficient on that scale.
Except that "walled gardens" are the infection vector in this case. It would be safer if people didn't download software from those weed infested cesspits and used Free software instead.
That's a stupid idea. To use an analogy that Slashdot understands: a traditional dictionary is like a standards document. It's useful to promote interoperability between speakers both during a single transaction (conversation between two parties), and also in log files (written documents to be read again later).
Collecting random words on the web into a dictionary is like getting rid of standards altogether, or saying that every piece of software out there, no matter what it does, is standards compliant. We saw what that leads to in the early browser wars.
We need language gate keepers. It's ok if language evolves somewhat over a period of 100 years, but if it changes so much that we can't make sense of what people wrote even 10 years ago, then we're in big trouble. In particular, dictionaries *shouldn't* be published more often than once every 25 years or so: It actually helps continuity if we force ourselves to use the same language that was current in the previous generation.
Due to budget downsizing and the retirement of high tech incarceration facilities, American prisoners will henceforth be housed in Russian gulags, where door locking vulnerabilities do not matter, since the main security algorithm depends only on thousands of kilometres of snow and ice...
That's a meaningless objection. Which BASIC are you thinking of as canonical?
The original language (and first historical version) is Dartmouth BASIC, which went through several version changes, adding new features over time. In its final version, the original BASIC was renamed True BASIC. The dialects available on micros didn't necessarily implement all the features of Dartmouth BASIC, for example matrix operations were missing from GW-BASIC or Commodore BASIC, IIRC.
And thank God for that, because I for one would not want to witness the
consequences of a Melissa or Slammer-type worm infecting every Android or iOS
device in the United States. We would just stop.
Well then, grab the popcorn and prepare to stop. It's trivial to build a Melissa or Slammer-type worm in a walled garden. Here's how:
You build an app that does something trivial and stupid like making fart noises. At the same time, it contains a hidden section that contains a virus. Remember, walled gardens allow non-free software, so they don't look at source code, so the virus won't be found.
Then one day when you're bored you leave a message to the fart app telling it to start spreading the virus. Bonus points if it can attach itself to other apps and spread from there, too.
This is the kind of project that might well interest a bored black hatter over the New Year break, don't you think?
1984 occurred in 1948. It was a caricature of the postwar British life experience. The Russians went from allies to enemies overnight, there was rationing until the early 50s, and the British class system was alive and well, notwithstanding the veneer of democracy and populism. Even propaganda via TV and Big Brother was already historical, as Germany's Goebbels had pioneered something like it (Germany was arguably a more modern country than Britain before the war).
If you don't have time for the entire 55-minute video,
I always have time for 55 minute videos, here's how you can, too:
1) download the video. When it's about half downloaded already,
2) start mplayer $VIDEO
Press the [ and ] keys a few times to speed up time to your liking. For talks I usually do x1.46, but YMMV. Start slowly, and when you're comfortable increase the speed. Keep increasing until it's too hard to understand.
As a rule, all the TV type media I watch is speeded up, and takes only half the normal running time to view. Try it.
And if that's the kind of programmer you're talking about, then you're wrong about BASIC's (lack of) suitability for their purposes.
For example, many if not most scientists and engineers write code today in languages like Matlab, which barely qualifies as a programming language. It has broadly speaking all the same kinds of limitations as BASIC in fact, and yet it's more productive than C or even Python because it fits a problem domain.
There's a prejudice among CS people in favour of "real" languages and generally procedural/object oriented ones at that, which misses the point that subject matter experts don't usually want a full fledged real language. What they want is something that's flexible in their problem domain, and they don't care much about other problem domains. In other words, a Little Language.
BASIC was invented by a mathematician, John
Kemeny, and a computer scientist Tom
Kurtz. They did this as part of a revolutionary change in how
students were taught mathematics, and suceeded admirably.
Here's an online version of
Kemeny's book Introduction
to Finite Mathematics with Laurie Snell and Gerald Thompson. What you have to understand is that this book looked nothing like the books on applied math of the day. It was truly revolutionary, and a lot of modern books have copied its ideas.
You'll also find that BASIC is very well suited to solving the kind of problems that are in that book. It's even arguable that BASIC's suitability for solving simple number crunching problems is what made the microcomputer revolution possible (remember, the killer app for the early PCs wasn't games, it was the spreadsheet - people bought micros so they could program compound interest...).
It's of course not so well suited for programming consumer software, but then again the language was invented 15 years before consumer software took off.
Depends entirely on what you want to do with it. BASIC is pretty nice for moderately complex calculations, and things like creating tables of information and so on, that a person might want do do for themselves with a minimum of fuss.
It's not any good for writing modern commercial software, but that wouldn't be the target demographic anyway.
We can say something looks like an interstellar spaceship, even though such a
thing does not exist. We can say it looks like a cave troll, which doesn't
exist -- except, of course, in stories. But then again, miracles definitely
exist in stories.
But that's the point. Interstellar spaceships do exist: Voyager is one. So if you were thinking of a small tin can with big antennas, then you weren't wrong.
But if you were thinking of big movie-style vessels with FTL drives and people inside, then your mental picture was defective, because no such thing exists and no such thing is physically possible if we're talking about hollywood FTL drives for example.
Just because we give something (putatively) a name and vaguely
describe some of its properties ("interstellar spaceship", "cave
troll", "miracle") doesn't mean it isn't an impossible idea, ie that
it is free from logical contradictions. And once there is a logical
contradiction, then everything is provable to be true and false
simultaneously.
That's why proving existence is crucial. It's not the only way to prove that an idea is consistent, but it's by far the simplest.
This question makes no sense at all and it's also irrelevant. How can you be
sure a cave troll won't make the universe disappear?
Exactly. We can't. We don't know that the idea "cave troll" isn't
self contradictory until we prove it, or find one and point to it.
However, a definition without a proof of existence is useless. Without existence, any definition might turn out self contradictory more likely than not.
How can you be sure that a "miracle" won't make the universe disappear?
Why are you saying you can't get paid as a software developer? You clearly can: get a job as a programmer, and your employer will pay you (once) for what you write for them during working hours, within about two weeks of the
work being done.
The same is true for authors. Get a job as a writer, and get paid (once) for the words you produce for your employer.
The whole not getting paid bullshit is really about gambling. The publishers gamble that they can sell (multiple times) a piece of writing to many people, and make a profit that way. That's always been hit or miss, when it pays off they make millions, and when it doesn't they take a loss.
But it's no concern to you. Unless you're the gambling type and decide to work for them on a contingency basis - get paid in royalties if the publisher's gamble pays off, and not if it doesn't. If that's what you're after, then more power to you, but don't whine about customers stealing your work when it's really that you gambled and lost. You should have got paid in advance.
You said it wasn't a major factor. Close enough in my book.
No, I said it wasn't the major risk factor. As long as you don't understand risk, you won't understand where the issues are from the companies' perspective.
Look, man. All you're doing is reinforcing my point. If you haven't done your
homework well, and don't know what to look for, then that's your problem.
No, that's every company's problem. You're not making an insightful
point if you hide risk under the label "homework". It's a messy fact that
must be taken into account.
In
the case of cars, I'd damned well do some catalogue shopping before I ever
went shopping for the real thing, so I'd already know what I was looking at
when you showed it to me!!!
Right, what exactly is the point of catalogue shopping? Those cars in the catalogues are all new, but I'm picking 10 random cars from the streets of America. You'd be better off looking at classifieds. And if you decide to only bid classified prices upfront, then I might think you're being cheap...
Or perhaps you're saying you'll keep playing the game round after round until I happen to present a brand new car among the choices? In that case you might wait a long time...
I'm not saying productivity isn't important. I'm saying it's not the main source of risk.
Let me give you a car analogy to illustrate risk. We'll play a game. You are going to bid for a car in advance, and I'm going to deliver a car to you. But here's the catch: I'll pick a list of 10 cars randomly among all the cars in America, and you get to look at each car for 30 seconds only. Then you either choose one or don't choose any. If you don't choose any, we'll repeat the game, but there's a small fee to play each game.
My question: how much are you willing to bid for the car sight unseen?
A car could be a brand new luxury vehicle, or a 20 year old rust bucket.
This is how hiring decisions are made. First, you decide on a project and figure out what budget you have etc. Then you advertise for employees who all tell you they're the greatest and smartest people on earth. You can adjust the amount you offer a candidate by a tiny amount only, but essentially the offer has already been decided in the budget weeks earlier.
You're overstating the importance of those variables. When a hire doesn't work out, neither productivity nor length of stay are major issues. The major issue is that they must be let go quickly and replaced.
In programming, the probability of competence is rather low when you
consider the pool of all programmers or self styled "software
engineers". Thus the risk of hiring a dud is high, and that's the main
source of risk. You can minimize that risk by hiring cheaper
employees, and that also reduces the cost of firing them. The cost of
finding a replacement is fixed.
Money and risk are two different things. Every hire is a risk. An
expensive hire is as much a risk as an inexpensive one, but more
expensive (duh). The result is that it makes more sense to go for the
inexpensive hire, because that reduces the costs in case things go bad.
Bad idea, a normal sized emacs poster needs 8 walls when fully unfolded, and the kids will be constantly swapping
the poster sections around whenever they want to open the door or the windows in the room. Why not try an ed(1) poster instead? It should fit snugly along a wall crack.
I'm Kevin Spacey. As you can see from my picture, I'm a good astronaut!
I'm available for Soyuz missions on most weekdays, but I have little league commitments every second weekend, and I like to head back home after 5pm if possible during the week. So call me, and let's get this thing off the ground for the new year!
Slashdot Mirror
To resolve the paradox, ask the question: Is a (regular) spot going to be used today? Is a (handicapped) spot going to be used today? In both cases the answer is about the same, and that means there's no overassignment at all, it's actually efficient on that scale.
Except that "walled gardens" are the infection vector in this case. It would be safer if people didn't download software from those weed infested cesspits and used Free software instead.
Collecting random words on the web into a dictionary is like getting rid of standards altogether, or saying that every piece of software out there, no matter what it does, is standards compliant. We saw what that leads to in the early browser wars.
We need language gate keepers. It's ok if language evolves somewhat over a period of 100 years, but if it changes so much that we can't make sense of what people wrote even 10 years ago, then we're in big trouble. In particular, dictionaries *shouldn't* be published more often than once every 25 years or so: It actually helps continuity if we force ourselves to use the same language that was current in the previous generation.
Due to budget downsizing and the retirement of high tech incarceration facilities, American prisoners will henceforth be housed in Russian gulags, where door locking vulnerabilities do not matter, since the main security algorithm depends only on thousands of kilometres of snow and ice...
The original language (and first historical version) is Dartmouth BASIC, which went through several version changes, adding new features over time. In its final version, the original BASIC was renamed True BASIC. The dialects available on micros didn't necessarily implement all the features of Dartmouth BASIC, for example matrix operations were missing from GW-BASIC or Commodore BASIC, IIRC.
Well then, grab the popcorn and prepare to stop. It's trivial to build a Melissa or Slammer-type worm in a walled garden. Here's how:
You build an app that does something trivial and stupid like making fart noises. At the same time, it contains a hidden section that contains a virus. Remember, walled gardens allow non-free software, so they don't look at source code, so the virus won't be found.
Then one day when you're bored you leave a message to the fart app telling it to start spreading the virus. Bonus points if it can attach itself to other apps and spread from there, too.
This is the kind of project that might well interest a bored black hatter over the New Year break, don't you think?
1984 occurred in 1948. It was a caricature of the postwar British life experience. The Russians went from allies to enemies overnight, there was rationing until the early 50s, and the British class system was alive and well, notwithstanding the veneer of democracy and populism. Even propaganda via TV and Big Brother was already historical, as Germany's Goebbels had pioneered something like it (Germany was arguably a more modern country than Britain before the war).
I always have time for 55 minute videos, here's how you can, too:
1) download the video. When it's about half downloaded already,
2) start mplayer $VIDEO
Press the [ and ] keys a few times to speed up time to your liking. For talks I usually do x1.46, but YMMV. Start slowly, and when you're comfortable increase the speed. Keep increasing until it's too hard to understand.
As a rule, all the TV type media I watch is speeded up, and takes only half the normal running time to view. Try it.
For example, many if not most scientists and engineers write code today in languages like Matlab, which barely qualifies as a programming language. It has broadly speaking all the same kinds of limitations as BASIC in fact, and yet it's more productive than C or even Python because it fits a problem domain.
There's a prejudice among CS people in favour of "real" languages and generally procedural/object oriented ones at that, which misses the point that subject matter experts don't usually want a full fledged real language. What they want is something that's flexible in their problem domain, and they don't care much about other problem domains. In other words, a Little Language.
I didn't mean removing but combining with...
You can also pirate it by removing the BSD and slapping a GPL on it. But technically that's not really piracy but buccaneering.
Except for all the scientists and engineers...
BASIC was invented by a mathematician, John Kemeny, and a computer scientist Tom Kurtz. They did this as part of a revolutionary change in how students were taught mathematics, and suceeded admirably.
Here's an online version of Kemeny's book Introduction to Finite Mathematics with Laurie Snell and Gerald Thompson. What you have to understand is that this book looked nothing like the books on applied math of the day. It was truly revolutionary, and a lot of modern books have copied its ideas.
You'll also find that BASIC is very well suited to solving the kind of problems that are in that book. It's even arguable that BASIC's suitability for solving simple number crunching problems is what made the microcomputer revolution possible (remember, the killer app for the early PCs wasn't games, it was the spreadsheet - people bought micros so they could program compound interest...).
It's of course not so well suited for programming consumer software, but then again the language was invented 15 years before consumer software took off.
Isn't cobbling a kind of assembly? Whoa! Infinite recursi^NO CARRIER
It's not any good for writing modern commercial software, but that wouldn't be the target demographic anyway.
But that's the point. Interstellar spaceships do exist: Voyager is one. So if you were thinking of a small tin can with big antennas, then you weren't wrong. But if you were thinking of big movie-style vessels with FTL drives and people inside, then your mental picture was defective, because no such thing exists and no such thing is physically possible if we're talking about hollywood FTL drives for example.
Just because we give something (putatively) a name and vaguely describe some of its properties ("interstellar spaceship", "cave troll", "miracle") doesn't mean it isn't an impossible idea, ie that it is free from logical contradictions. And once there is a logical contradiction, then everything is provable to be true and false simultaneously.
That's why proving existence is crucial. It's not the only way to prove that an idea is consistent, but it's by far the simplest.
Exactly. We can't. We don't know that the idea "cave troll" isn't self contradictory until we prove it, or find one and point to it.
How can you be sure that a "miracle" won't make the universe disappear?
The same is true for authors. Get a job as a writer, and get paid (once) for the words you produce for your employer.
The whole not getting paid bullshit is really about gambling. The publishers gamble that they can sell (multiple times) a piece of writing to many people, and make a profit that way. That's always been hit or miss, when it pays off they make millions, and when it doesn't they take a loss.
But it's no concern to you. Unless you're the gambling type and decide to work for them on a contingency basis - get paid in royalties if the publisher's gamble pays off, and not if it doesn't. If that's what you're after, then more power to you, but don't whine about customers stealing your work when it's really that you gambled and lost. You should have got paid in advance.
No, I said it wasn't the major risk factor. As long as you don't understand risk, you won't understand where the issues are from the companies' perspective.
No, that's every company's problem. You're not making an insightful point if you hide risk under the label "homework". It's a messy fact that must be taken into account.
Right, what exactly is the point of catalogue shopping? Those cars in the catalogues are all new, but I'm picking 10 random cars from the streets of America. You'd be better off looking at classifieds. And if you decide to only bid classified prices upfront, then I might think you're being cheap...
Or perhaps you're saying you'll keep playing the game round after round until I happen to present a brand new car among the choices? In that case you might wait a long time...
Let me give you a car analogy to illustrate risk. We'll play a game. You are going to bid for a car in advance, and I'm going to deliver a car to you. But here's the catch: I'll pick a list of 10 cars randomly among all the cars in America, and you get to look at each car for 30 seconds only. Then you either choose one or don't choose any. If you don't choose any, we'll repeat the game, but there's a small fee to play each game.
My question: how much are you willing to bid for the car sight unseen? A car could be a brand new luxury vehicle, or a 20 year old rust bucket.
This is how hiring decisions are made. First, you decide on a project and figure out what budget you have etc. Then you advertise for employees who all tell you they're the greatest and smartest people on earth. You can adjust the amount you offer a candidate by a tiny amount only, but essentially the offer has already been decided in the budget weeks earlier.
In programming, the probability of competence is rather low when you consider the pool of all programmers or self styled "software engineers". Thus the risk of hiring a dud is high, and that's the main source of risk. You can minimize that risk by hiring cheaper employees, and that also reduces the cost of firing them. The cost of finding a replacement is fixed.
Money and risk are two different things. Every hire is a risk. An expensive hire is as much a risk as an inexpensive one, but more expensive (duh). The result is that it makes more sense to go for the inexpensive hire, because that reduces the costs in case things go bad.
What? If it doesn't count as war, then it counts as spam, and I HATE spam! Time to build some thermonuclear spam filters...
Bad idea, a normal sized emacs poster needs 8 walls when fully unfolded, and the kids will be constantly swapping the poster sections around whenever they want to open the door or the windows in the room. Why not try an ed(1) poster instead? It should fit snugly along a wall crack.
Hi,
I'm Kevin Spacey. As you can see from my picture, I'm a good astronaut!
I'm available for Soyuz missions on most weekdays, but I have little league commitments every second weekend, and I like to head back home after 5pm if possible during the week. So call me, and let's get this thing off the ground for the new year!