Quite a lot. See, when they can't pay repeatedly, the state will start garnishing their wages AND hit them with a fee for not paying the fine. And then a fee for not paying that etc. It's pretty much like compound interest.
So with that extra 25%, they won't be able to pay it out for longer, and hence the state (and similarly "helpful" private companies that it subcontracts to) can milk them for longer.
I rather think you didn't understand the answer (or chose not to "in a vain attempt to look smart"?), but whatever. I should have known better, given how you chose to name yourself.
I do hope you aren't actually teaching kids, though. The worst kind of people are those who are wrong, but are utterly convinced that they're not, because they had a teacher who was very good at teaching them those wrong things in a very convincing way.
There are definitely languages out there that make good use of "y" (Norwegian is another good example). But I would argue that English is not one of them, at least not in this particular case.
Oh, also: "q". The single most useless letter of the Latin alphabet. Ironically, the languages that get most use of it are non-Indo-European (e.g. various Turkic ones, transliteration of Arabic etc - where it usually means IPA/q/).
When there is no financial incentive to waste electricity making heat the blockchain can be easily circumvented with a 51% attack.
The financial incentive doesn't have to come from the blockchain directly in the form of currency. It can come from the desire to not see the blockchain compromised (e.g. when your economy depends on it).
Oh, rest assured, I can fathom it just fine. You see, I am a gun owner who owns over 30 guns, including several "assault weapons" and NFA items; and I also carry a handgun, and have more than one around at home myself (all of them either in one of the several safes, or with secure locking devices that block the action). Obviously, I know quite a few other people who are gun owners. So I see quite a bit of gun culture in US.
The children of responsible gun owners are taught at an early age that guns are not toys to be played with.
They're taught that, yes. And then those "responsible gun owners" are surprised to find out that, hey! a 7 year old kid doesn't fully grok the meaning of things like "responsibility", or when they do, they're still unable to resist their natural curiosity. Watch this video. All of those kids have parents who are gun owners, who believed themselves to be "responsible gun owners" because they taught their kids how to behave around guns - and were pretty sure that those lessons were learned.
If looking at this video and not shrugging it off means I'm a "pussy", then so be it. You, on the other hand, are an idiot. I sure hope that you don't actually have kids; but if you do, and they find your unsecured gun and shoot themselves or someone else with it, I want you to be legally responsible for your idiocy, especially now that you cannot even claim to not know how and why it's dangerous.
But you probably assume all gun owners leave their guns lying on the coffee table, fully loaded, with a houseful of ignorant children running around.
If you don't leave a gun either fully unloaded (and with no access to magazines and/or ammo), or secure it in a safe, or carried on your person, anywhere else you'd put it at home is basically equivalent to what you've described. Kids are reckless, but they're not stupid. They can, and will, find out where you store it, and if it is not locked, they will retrieve it, and play with it.
carrying a gun on your person is a good way to get shot or arrested in many areas and states in the US. You should try it sometime.
I'm not aware of any states in the Union that ban carry in the privacy of your own home (which is the only thing relevant to this particular discussion), whether open or concealed.
Even beyond your home, vast majority of states have legal provisions for shall-issue concealed carry today.
I've been carrying a gun in my pocket pretty much daily for the past 5 years. No-one has even realized that I have one, unless and until I chose to share it with them (and no-one has ever asked if I do).
The "dirty box" analogy is actually kinda good also because it "explains" why, even though you can store different things in the same box at different times, you don't really want to in most cases (i.e. why even in a dynamically typed language, it's probably not a good idea to say x=1 on one line, and then x="abc" right after). On the other hand, the fact that you can do so is still useful in a pinch (e.g. if you suddenly have to move, you grab whatever boxes you have and stuff whatever fits).
But honestly, it's just not a big deal either way. Variables just operate differently in different languages when it comes to detailed semantics, and there are more models than the two we have discussed (e.g. in Haskell and similar functional language, variables don't store values, they bind to values - so it's not a box, but more like a sticky note that you can write something on once, and then you have to discard it and get a different note if you want to write something else).
The key concepts are variables in general, conditionals, loops/recursion, functions, general notion of aggregate data structures (collections etc), and reactiveness (observers/events/...). If a language handles all of these adequately with minimum overhead from other concepts, it's good to go for teaching of basic programming literacy. And once on that level, an "industrial strength" language like Java can be tackled directly by mapping those concepts to things in that language, and covering new ones, explaining them in terms of old ones (e.g. OOP = aggregation + functions, at its core).
The nice thing about Python is that it covers both levels - it pretty much gets out of your way when teaching basic stuff (you don't need to explain "import", "class", "#include" or "main" to write a hello world app), but it still has all the bits of a full-fledged modern programming language, and it weaves them everywhere in an inconspicuous ways. For example, you can explain numbers and strings and lists, and operations on them, without delving into OOP (the only bit that you'll need to gloss over is the dot-syntax for things like "abc".startswith("a"), but it's very easy); and then later, when you do get into OOP proper, you can rewind and explain how "everything is an object", and recast some older code samples from that perspective.
Good thing I wasn't explaining it to a 9 year old kid, then.
As for the kid, I'd just give them Python and tell them that boxes magically appear when they need them (or better yet, that they're always there, on the shelf).
No, being a pussy is not an excuse to having unsecured firearms. You don't magically become any less of a pussy by being in a presence of a gun, unsecured or otherwise.
(And BTW, carried on your person counts as "secured".)
This explains what variables are, and why they're typed, but not why you need to declare them. When you write in Python, you're basically saying things like "I put 1 into box X", and you get a box labeled "X" right there and then, when you need it. When you write in C, it's the same, except you have to ask for all the boxes in advance - you don't get any later. There's no obvious advantage to the later from this high-level perspective; a kid would take away that C is strict and Python is not, but they wouldn't know why strict is better.
Of course, an astute kid would also point out that a box can be used for different things (of the right size), too, just not at the same time. So a box can hold a cookie now, and it can hold a shoe later, and then a cookie again. You don't need boxes of different color or anything. Again, this is exactly how Python works (variables don't have types, but they hold values which do have types), and less like C.
It doesn't matter. Single-issue voters are a minority voting block for sure, but it's a powerful block precisely because it's single-issue. Basically, you have two politicians, one is pro-gun-control, other is not, and they have 10 other issues they disagree on. Most voters would look at those other issues first, and guns will play a fleeting role in making the choice one way or the other. But that 5% (or maybe even less) of single-issue voters will pick the guy against gun control and disregard everything else. And there's no similar block that does the same on the pro-gun-control side of things.
This is exactly why you have the situation where 90% of Americans want universal background checks, but Congress won't pass it because no Republican will vote for it. They all know that if they don't vote for it, they won't lose any votes over that (other issues are more important), but if they do vote for it, they'll lose that 5% immediately.
Similar laws have been proposed in California. Given the overall climate on the subject of gun control there, they're virtually guaranteed to pass once they're submitted.
I fail to see how this makes an argument in favor of smart guns. The situation on the range couldn't have been avoided by one, since the gun was deliberately placed in the child's hand loaded and ready to fire - and she was instructed to do just that.
In what sense it is a failure? They failed a single launch for a larger prototype, seemingly for no reasons connected to the prototype itself, and then funding dried up. But the prototype that they did succeed with showed that the idea is sound.
Where does this leave Microsoft's own products like Visual Studio and Office etc.? These sorts of applications just don't seem to fit the RT format, and Microsoft's own reluctance to move to them from a more classical desktop format seems to be an admittance in itself that if nothing else RT just isn't a format that is going to work for every desktop application. Maybe it's me that's at fault, but I just can't see how I can build our application decently to suit this "app" format that RT pushes - it's like switching Visual Studio to this "app" format, I just don't see it happening without crippling the product. In fact, Visual Studio hasn't of course even made the switch to ribbons and so presumably there must be at least some recognition at MS that not everything can be a tablet friendly app and that more classic development support is still going to be necessary for the foreseeable future? Unless we regress back to MFC, which does of course seem to be supported at least I don't see how WPF or at least something very much like it can ever go away.
Well, the boundaries of the "app format" have been vastly expanded in Win10 compared to the severely crippled sandbox that was there in Win8/8.1,and I'm hoping that it will continue to the point where something like VS actually can fit just fine. And if you look at the Win10 desktop today, WinRT apps actually feel much less "tablet-y" also - part of it is running windowed rather than fullscreen, but there are smaller changes in the same vein, too - e.g the shift away from all these hidden panels that you had to swipe out to clickable controls (for charms, app bar etc), and just generally scaling down of controls in non-touch modes. It still encourages writing apps that work well with touch, but if you wanted to ignore that and go for mouse-only, you could.
But yes, for near future, and for managed desktop UI apps, it's definitely WPF.
In terms of sandboxing therefore, I think it'd be sufficient to merely restrict the methods they can call to those in our standard library.... One thing is for sure though and that's that we can't simply persist with a setup that allows execution of arbitrary Lua using the standard unmanaged interpreter and all the problems that brings.
If all you want to do is lock down which functions it calls, then I'm not sure why stock Lua is an issue? It's deliberately designed to be very lockable in that fashion.
Slashdot Mirror
Quite a lot. See, when they can't pay repeatedly, the state will start garnishing their wages AND hit them with a fee for not paying the fine. And then a fee for not paying that etc. It's pretty much like compound interest.
So with that extra 25%, they won't be able to pay it out for longer, and hence the state (and similarly "helpful" private companies that it subcontracts to) can milk them for longer.
http://thesocietypages.org/pap...
I rather think you didn't understand the answer (or chose not to "in a vain attempt to look smart"?), but whatever. I should have known better, given how you chose to name yourself.
I do hope you aren't actually teaching kids, though. The worst kind of people are those who are wrong, but are utterly convinced that they're not, because they had a teacher who was very good at teaching them those wrong things in a very convincing way.
Yes. And I explained to you why your explanation wasn't good enough.
There are definitely languages out there that make good use of "y" (Norwegian is another good example). But I would argue that English is not one of them, at least not in this particular case.
Oh, also: "q". The single most useless letter of the Latin alphabet. Ironically, the languages that get most use of it are non-Indo-European (e.g. various Turkic ones, transliteration of Arabic etc - where it usually means IPA /q/).
Yes, good point. But why stop at accents. All diacritics are stupid.
Few people care about Bitcoin. A lot more care about blockchain technology, including major banks and IT firms.
When there is no financial incentive to waste electricity making heat the blockchain can be easily circumvented with a 51% attack.
The financial incentive doesn't have to come from the blockchain directly in the form of currency. It can come from the desire to not see the blockchain compromised (e.g. when your economy depends on it).
Why stop at 26? Can anyone hear the difference between "i" and in "mist", and "y" in "mystery"?
Why have "c", when you have "k" and "s"?
So, when are we removing the accent from "i"?
It depends on which kind of present tense (i.e. which meaning you're trying to convey). English has more than one.
Oh, so you're even more of an idiot, because you're regurgitating other people's talking points without any personal experience whatsoever?
Oh, rest assured, I can fathom it just fine. You see, I am a gun owner who owns over 30 guns, including several "assault weapons" and NFA items; and I also carry a handgun, and have more than one around at home myself (all of them either in one of the several safes, or with secure locking devices that block the action). Obviously, I know quite a few other people who are gun owners. So I see quite a bit of gun culture in US.
The children of responsible gun owners are taught at an early age that guns are not toys to be played with.
They're taught that, yes. And then those "responsible gun owners" are surprised to find out that, hey! a 7 year old kid doesn't fully grok the meaning of things like "responsibility", or when they do, they're still unable to resist their natural curiosity. Watch this video. All of those kids have parents who are gun owners, who believed themselves to be "responsible gun owners" because they taught their kids how to behave around guns - and were pretty sure that those lessons were learned.
If looking at this video and not shrugging it off means I'm a "pussy", then so be it. You, on the other hand, are an idiot. I sure hope that you don't actually have kids; but if you do, and they find your unsecured gun and shoot themselves or someone else with it, I want you to be legally responsible for your idiocy, especially now that you cannot even claim to not know how and why it's dangerous.
But you probably assume all gun owners leave their guns lying on the coffee table, fully loaded, with a houseful of ignorant children running around.
If you don't leave a gun either fully unloaded (and with no access to magazines and/or ammo), or secure it in a safe, or carried on your person, anywhere else you'd put it at home is basically equivalent to what you've described. Kids are reckless, but they're not stupid. They can, and will, find out where you store it, and if it is not locked, they will retrieve it, and play with it.
carrying a gun on your person is a good way to get shot or arrested in many areas and states in the US. You should try it sometime.
I'm not aware of any states in the Union that ban carry in the privacy of your own home (which is the only thing relevant to this particular discussion), whether open or concealed.
Even beyond your home, vast majority of states have legal provisions for shall-issue concealed carry today.
I've been carrying a gun in my pocket pretty much daily for the past 5 years. No-one has even realized that I have one, unless and until I chose to share it with them (and no-one has ever asked if I do).
But tell me more about your plight.
I don't have a kid :)
The "dirty box" analogy is actually kinda good also because it "explains" why, even though you can store different things in the same box at different times, you don't really want to in most cases (i.e. why even in a dynamically typed language, it's probably not a good idea to say x=1 on one line, and then x="abc" right after). On the other hand, the fact that you can do so is still useful in a pinch (e.g. if you suddenly have to move, you grab whatever boxes you have and stuff whatever fits).
But honestly, it's just not a big deal either way. Variables just operate differently in different languages when it comes to detailed semantics, and there are more models than the two we have discussed (e.g. in Haskell and similar functional language, variables don't store values, they bind to values - so it's not a box, but more like a sticky note that you can write something on once, and then you have to discard it and get a different note if you want to write something else).
The key concepts are variables in general, conditionals, loops/recursion, functions, general notion of aggregate data structures (collections etc), and reactiveness (observers/events/...). If a language handles all of these adequately with minimum overhead from other concepts, it's good to go for teaching of basic programming literacy. And once on that level, an "industrial strength" language like Java can be tackled directly by mapping those concepts to things in that language, and covering new ones, explaining them in terms of old ones (e.g. OOP = aggregation + functions, at its core).
The nice thing about Python is that it covers both levels - it pretty much gets out of your way when teaching basic stuff (you don't need to explain "import", "class", "#include" or "main" to write a hello world app), but it still has all the bits of a full-fledged modern programming language, and it weaves them everywhere in an inconspicuous ways. For example, you can explain numbers and strings and lists, and operations on them, without delving into OOP (the only bit that you'll need to gloss over is the dot-syntax for things like "abc".startswith("a"), but it's very easy); and then later, when you do get into OOP proper, you can rewind and explain how "everything is an object", and recast some older code samples from that perspective.
Good thing I wasn't explaining it to a 9 year old kid, then.
As for the kid, I'd just give them Python and tell them that boxes magically appear when they need them (or better yet, that they're always there, on the shelf).
No, being a pussy is not an excuse to having unsecured firearms. You don't magically become any less of a pussy by being in a presence of a gun, unsecured or otherwise.
(And BTW, carried on your person counts as "secured".)
This explains what variables are, and why they're typed, but not why you need to declare them. When you write in Python, you're basically saying things like "I put 1 into box X", and you get a box labeled "X" right there and then, when you need it. When you write in C, it's the same, except you have to ask for all the boxes in advance - you don't get any later. There's no obvious advantage to the later from this high-level perspective; a kid would take away that C is strict and Python is not, but they wouldn't know why strict is better.
Of course, an astute kid would also point out that a box can be used for different things (of the right size), too, just not at the same time. So a box can hold a cookie now, and it can hold a shoe later, and then a cookie again. You don't need boxes of different color or anything. Again, this is exactly how Python works (variables don't have types, but they hold values which do have types), and less like C.
Who said anything about "being armed all the times"?
It doesn't matter. Single-issue voters are a minority voting block for sure, but it's a powerful block precisely because it's single-issue. Basically, you have two politicians, one is pro-gun-control, other is not, and they have 10 other issues they disagree on. Most voters would look at those other issues first, and guns will play a fleeting role in making the choice one way or the other. But that 5% (or maybe even less) of single-issue voters will pick the guy against gun control and disregard everything else. And there's no similar block that does the same on the pro-gun-control side of things.
This is exactly why you have the situation where 90% of Americans want universal background checks, but Congress won't pass it because no Republican will vote for it. They all know that if they don't vote for it, they won't lose any votes over that (other issues are more important), but if they do vote for it, they'll lose that 5% immediately.
http://www.npr.org/sections/al...
Similar laws have been proposed in California. Given the overall climate on the subject of gun control there, they're virtually guaranteed to pass once they're submitted.
As in, it's not a libertarian circle jerk?
They actually make gun safes that can be opened "right now", if one fancies such a thing.
There really isn't any excuse to have unsecured firearms around the house, no matter how paranoid you are.
I fail to see how this makes an argument in favor of smart guns. The situation on the range couldn't have been avoided by one, since the gun was deliberately placed in the child's hand loaded and ready to fire - and she was instructed to do just that.
In what sense it is a failure? They failed a single launch for a larger prototype, seemingly for no reasons connected to the prototype itself, and then funding dried up. But the prototype that they did succeed with showed that the idea is sound.
The guy who is behind this thing is claiming that the entire system can be built and launched for under a billion.
(Note that a single launch can launch several mirror satellites.)
Where does this leave Microsoft's own products like Visual Studio and Office etc.? These sorts of applications just don't seem to fit the RT format, and Microsoft's own reluctance to move to them from a more classical desktop format seems to be an admittance in itself that if nothing else RT just isn't a format that is going to work for every desktop application. Maybe it's me that's at fault, but I just can't see how I can build our application decently to suit this "app" format that RT pushes - it's like switching Visual Studio to this "app" format, I just don't see it happening without crippling the product. In fact, Visual Studio hasn't of course even made the switch to ribbons and so presumably there must be at least some recognition at MS that not everything can be a tablet friendly app and that more classic development support is still going to be necessary for the foreseeable future? Unless we regress back to MFC, which does of course seem to be supported at least I don't see how WPF or at least something very much like it can ever go away.
Well, the boundaries of the "app format" have been vastly expanded in Win10 compared to the severely crippled sandbox that was there in Win8/8.1,and I'm hoping that it will continue to the point where something like VS actually can fit just fine. And if you look at the Win10 desktop today, WinRT apps actually feel much less "tablet-y" also - part of it is running windowed rather than fullscreen, but there are smaller changes in the same vein, too - e.g the shift away from all these hidden panels that you had to swipe out to clickable controls (for charms, app bar etc), and just generally scaling down of controls in non-touch modes. It still encourages writing apps that work well with touch, but if you wanted to ignore that and go for mouse-only, you could.
But yes, for near future, and for managed desktop UI apps, it's definitely WPF.
In terms of sandboxing therefore, I think it'd be sufficient to merely restrict the methods they can call to those in our standard library. ... One thing is for sure though and that's that we can't simply persist with a setup that allows execution of arbitrary Lua using the standard unmanaged interpreter and all the problems that brings.
If all you want to do is lock down which functions it calls, then I'm not sure why stock Lua is an issue? It's deliberately designed to be very lockable in that fashion.
Or are you concerned more about perf after all?