Have you ever actually used Python 2 and Python 3?
Yes, I use both. 3 for new projects where broad compatibility is not an issue, and 2 for the legacy projects that are already in place in 2, tested and spec-complete. Differences like...
o print "this is a print statement", o print("this is a print statement", end=" ")
...thoroughly break existing code. That's all it takes, although of course there is more like that. My assertion is that when a language breaks perfectly good, spec-compliant code, it's a new language.
Python 3 is not Python specifically because it will not run Python 2 code. Python 3 isn't just a "little" different. It's a lot different. Which is fine. Although they should have called it something other than Python, frankly, because it confuses a lot of people that Python != Python. Justifiably so.
Swift appears to be undergoing the exact same schism. The new Swift is not the old Swift; if it breaks your compliant code, it's a new language. If it breaks some undocumented crap, that's something else entirely. But when you write to spec, and the New/Shiny won't run it -- that's an entirely new language, regardless of what little, or lot, remains syntax compatible. Swift != Swift.
Python's 2-series remains 100% viable; the source code is out there. Dunno about Swift; I code Python all the time, haven't bothered with Swift (nor am I ever likely to.)
My insignificant little message to all language designers is this: Once you make a spec beyond beta, if you break the spec, you're developing an entirely new language, and you should REALLY change the damned name.
I write applications (big ones) for OS X using c and c++. Targeting 10.6.8, my code still works fine under 10.11 today. It ports to Windows easily as well. Re Windows, targeting XP, it all works right up to the current version of Windows. XP broke the OS windowing metrics, otherwise my stuff would still work with Win98.:) Apple hasn't done anything quite that stupid. Well, yet. 10.6.8 is where 64-bit code began to work; and it's the last OS X that supports PPC (my HP calculator emulation, bunch of audio drivers, my old mame (which is actually fairly important to me, because some of those games are my code, and code from close friends in the day, and I want that stuff to work as long as possible), all kinds of stuff in Appleworks, etc., etc. So 10.6.8 is where I planted my flag, so to speak.
Of course if you decide Swift or Objective C is your chosen coding mechanism, that's fine, but there's no externally imposed requirement that it must be your coding mechanism; at the worst, a few boilerplate intermediate layers based on basic OS APIs will do ya.
Sometimes -- for instance, with Apple's OS file dialogs -- the stuff Apple supplies is either broken, feature-poor, or both. After being bitten over and over by that stupid file dialog, I spent an afternoon and wrote my own. Which works a damn sight better, and faster, and with less hangups than Apple's does. My users benefit a great deal from my unwillingness to let Apple screw them with the bug-infested trail of tears they leave behind them as they blunder onwards into their new and shinier future.
Same thing for most (all?) of Apple and Microsoft's "new and shiny." For every new thing you decide you depend on in the OS, you're leaving users behind, and making your code more and more dependent upon Apple's latest whim.
Which, again, you can do, absolutely -- but you don't have to.
Almost every time I see some application that "requires" some fairly late version of an operating system, I think dark thoughts. There are few things, particularly things that are focused upon new features, where it is likely reasonable. But mostly... not. Mostly it's just thoughtless development where the user takes a back seat to... let's face it: "shiny."
Depends on where you live. Here in Montana, we have 120v AC plugs at most parking spaces where employees park. These have been used to run our engine block and battery heaters -- otherwise, on our -40 days, you go back out after your 8 hours of wage-slavery and your vehicle is not very likely to start unless you've come out several times and warmed it back up (and on windy days, even that doesn't work.)
So here, slow-charging, at least, should be available to some extent. I do wonder what the combined load of block/battery heaters + battery charge will be; related, if you can tell the vehicle to limit the charge rate to, say, 10 amps; and how employers will feel about providing same... but they'll figure something out. They'll have to.
A lot of people here have garages (same reason... parking outdoors can be rough in winter) and it seems to me that the sensible time to charge regular-use short-to-medium distance use EVs is at night anyway.
Looking forward to it, however it goes. I'll keep my 4WD pickup for the really nasty weather and transport of heavy stuff, but EVs are my target for most driving and the Tesla looks like what I want at the moment. Assuming, again, that they can produce enough so I can actually buy one.
"for free" meaning, you paid a hell of a lot more for your vehicle and part of that went for supercharger use.
Funny use of "for free", but okay.
Me, I'm looking forward to my "not for 'free'" electricity consuming Tesla, if they can just get them built. Breath-holding does not seem to be called for here.
The fourth amendment says nothing about "third parties." Not one word.
This is just more judicial activism continuing to bite the citizens in the posterior.
Reasonable = probable cause, oath or affirmation, description(s) of place to be searched and item(s) to be seized, which allow for a warrant to be issued. Anything else = UNreasonable.
Anything the justices say to the contrary is in direct violation of their oath of office.
You gotta RAM as many CORES into her BUS as possible.
If you go down this road carelessly, you'll end up with an ultra-wide bus. So consider server back door operation, as this is generally an underutilized port. Make sure you employ Logical Unit Bus Expansion tech in both cases; otherwise bus errors are much more likely to occur. Note that as with all bus expansions, you must arrange for the bus impedance to be low; this requires low resistance, and also, if capacitance is relatively high, you'll find that although the bus will work to some degree at low rates, data will be lost trying to charge surfaces that exceed the capacity of the bus driver. Should you have to deal with a high-capacity system, large auxillary drivers can compensate for this. In my designs, I have found that stocking the right components tends to skirt problems up front WRT driver installation procedures, and with the drivers themselves, as full access to the bus is available without having to completely strip the hardware to the chassis. Please note that installations should always undergo vibratory stress testing under full load as a precursor to customer acceptance. This also tends to increase long term bus compliance.
Bleached coral is not always dead. Bleaching is caused by expulsion of the symbionts with the intent of acquiring new symbionts more able to produce nutrients under the current conditions.
Death occurs in situations like this only if symbionts do not arrive and the coral starves.
The media tends to overlook the details. As usual.
Features are one thing. That's a perfectly valid way to sell a new device.
However, bugfixes during a product's normal lifetime are another thing entirely.
I am of the opinion that if you sell a piece of software, first, you should specify what it is you are selling it to do, and the environment within which you are claiming it will do these things. Which we can take, at least at the moment, as "the feature list." If the software does not do what you said it would do, or work in the environment you said it would the way you said it would, then I believe you have two, and only two, valid ethical choices:
o Fix it o Refund the customer's payment
Similarly, if the software does something harmful that you failed to notify the buyer of before the sale, I believe you have two, and only two, valid ethical choices:
o Fix it o Refund the customer's payment (and depending on your original claims, there may be liability as well.)
I think the mindset that software producers have been allowed to develop that they can leave a trail of broken and never-to-be fixed software behind them, while proceeding forward on the proceeds made from said broken products, has led to a serious downside: that we very rarely actually end up with working software. Instead, we get new software. It's... shiny. Those new features glow like a fancy new chrome bumper. But because it's not actually fixed, it's new, it often (very often, especially in the case of operating systems) causes other things to fail where they used to work just fine, because slipped in their with "new features" are often "yeah, we changed that, it's NEW!" Whereas, if, for instance, Apple had actually fixed the printing bugs for OS X 10.6.8, then those things that were working in that environment otherwise would then have had access to printing functionality as originally claimed by Apple, and stability, reliability and functionality would be optimized.
An example I am familiar with: If you stick with OS X 10.6.8 on some Mac Minis, then you suffer with a permanently broken printing system in some respects with some CPUs (core duo, IIRC), and if you also depend on 10.6.8 features/capabilities (such as PPC emulation, for instance) then 10.7 and beyond are not an option, therefore you are permanently broken.
This is just an Apple example. I know Microsoft left the Windows file dialog broken for multiple selection in various releases of Windows, never fixing the problem. To this day, if you select too many files in the most-fixed version of some Windows releases, you'll experience bugs. Another: in some versions of Windows, the font rotation API went clockwise, and in others, it went counter-clockwise. Instead of actually fixing it, Microsoft had us special-case the OS by version. I feel reasonably sure experienced Linux users could supply similar examples in the various commercial Linux distributions where to get a fix, you actually need a shiny new version of Linux, rather than the version you already have, actually fixed and still 100% compatible otherwise.
What I'm trying to get across here is that I think that we, as users, should do a more thorough job of holding developer's feet to the fire when they give us broken stuff. Speaking as a developer, I try to live this; if bugs are reported to me during the life of a commercial product, then that product's life does not end until those bugs are fixed. I've been doing this with my freeware, also. And -- at least for me -- I find it very satisfying to bring the product as close as possible to what I claimed / thought it was in the first place. I don't like bugs.
Apple's the company I am most familiar with as I've been using OS X for quite a while now. And I can tell you that my feelings about Apple's choices WRT bug fixes and leaving broken crap behind them are not in any way positive, respectful, or satisfied.
We can do better. I actively try to do better. And I don't have hundreds of billions of dollars in the bank to back me up, either.
Wait until there's actual AI software (as opposed to the LDNLS people are mistakenly calling "AI" now.) Then we'll have intelligent, conscious... numbers. That no one can own (hopefully, we've learned our lesson on slavery.... okay, I'm being way too optimistic here, but roll with it.)
Now numbers can vote, own property... Instead of a digital artwork's "owner", you could end up its "guardian."
Perhaps we shouldn't go with "it's a number" after all.:)
As a parent, are you not old enough (informed enough should be the metric, but our society is bewildered about age) to decide if your kids can use the device?
Oh, right, parenting. Not allowed to do that any longer, my bad. "It takes a village" (to pillage your informed personal and consensual choices, not to mention parenting.) Of course you're not old enough. We'll decide that for you. Move along. Move along.
There are indeed. However, those limits are moving constantly, and in the less-limited direction. While worker costs are steadily increasing on multiple fronts even without wage increases.
Don't assume automation won't get to a point where it can't do what's required in a job that is essentially repetitive in nature. That's an extremely poor bet. Not only is more competent, acceptably abled automation going to happen, it's going to happen fairly soon in the fast food industry, where many franchise instances create significant financial motivation for automation manufacturers -- two to three years is my estimate.
government caused this problem by not allowing wages to settle at $5/hour
All wages at $5 an hour do is make the rest of us support the workers via the social safety nets.
And if you take the social safety nets away, then you have people who are earning $200/week for 40 hours labor.
That means no medical care, rent is impossible to pay in many circumstances, etc., etc., ad nauseum.
Even as it stands now, we subsidize those corporations with our taxes; that's the only thing that makes the wages they pay now survivable in any real sense of the word in any urban environment. Small town or country living, maybe you can make some kind of sane go of it for less than $10/hour, but it's definitely the exception, not the rule.
For McDonald's and the like, when the cost of functionally adequate automation falls below the cost of employment, they're going to move to automation. We either figure out how to handle the consequences ahead of time, or we take the beating when it happens without any fallback position. My guess is that it will probably be the latter, inasmuch as politics-as-usual always seem to target only the nearest term headlights-in-the-tunnel.
Also... speaking now with my AI researcher hat on: I think it's a slam dunk that the automation that will suit the fast food service industries is going to arrive very, very soon. With other service industries soon to follow. This problem is basically on our doorstep right now. Most people fail to see it because it represents a paradigm shift - things will be as they have never been before in history, and it's just very difficult to imagine fundamental changes in one's worldview that have no precedent.
Grab the popcorn and lock your doors. Show's going to start shortly.
We're not talking about the same things. I never said services don't cost money, or that he should be free of taxes.
I said that more than 2x as much of your income goes to taxes.
Which is precisely correct.
These are the facts behind the argument that corporations should not pay taxes. When they do, they just build it into the product, and YOU pay the taxes. You don't get any more product. You just pay a higher price.
Slashdot Mirror
Yes, I use both. 3 for new projects where broad compatibility is not an issue, and 2 for the legacy projects that are already in place in 2, tested and spec-complete. Differences like...
o print "this is a print statement",
o print("this is a print statement", end=" ")
Python 3 is not Python specifically because it will not run Python 2 code. Python 3 isn't just a "little" different. It's a lot different. Which is fine. Although they should have called it something other than Python, frankly, because it confuses a lot of people that Python != Python. Justifiably so.
Swift appears to be undergoing the exact same schism. The new Swift is not the old Swift; if it breaks your compliant code, it's a new language. If it breaks some undocumented crap, that's something else entirely. But when you write to spec, and the New/Shiny won't run it -- that's an entirely new language, regardless of what little, or lot, remains syntax compatible. Swift != Swift.
Python's 2-series remains 100% viable; the source code is out there. Dunno about Swift; I code Python all the time, haven't bothered with Swift (nor am I ever likely to.)
My insignificant little message to all language designers is this: Once you make a spec beyond beta, if you break the spec, you're developing an entirely new language, and you should REALLY change the damned name.
I write applications (big ones) for OS X using c and c++. Targeting 10.6.8, my code still works fine under 10.11 today. It ports to Windows easily as well. Re Windows, targeting XP, it all works right up to the current version of Windows. XP broke the OS windowing metrics, otherwise my stuff would still work with Win98. :) Apple hasn't done anything quite that stupid. Well, yet. 10.6.8 is where 64-bit code began to work; and it's the last OS X that supports PPC (my HP calculator emulation, bunch of audio drivers, my old mame (which is actually fairly important to me, because some of those games are my code, and code from close friends in the day, and I want that stuff to work as long as possible), all kinds of stuff in Appleworks, etc., etc. So 10.6.8 is where I planted my flag, so to speak.
Of course if you decide Swift or Objective C is your chosen coding mechanism, that's fine, but there's no externally imposed requirement that it must be your coding mechanism; at the worst, a few boilerplate intermediate layers based on basic OS APIs will do ya.
Sometimes -- for instance, with Apple's OS file dialogs -- the stuff Apple supplies is either broken, feature-poor, or both. After being bitten over and over by that stupid file dialog, I spent an afternoon and wrote my own. Which works a damn sight better, and faster, and with less hangups than Apple's does. My users benefit a great deal from my unwillingness to let Apple screw them with the bug-infested trail of tears they leave behind them as they blunder onwards into their new and shinier future.
Same thing for most (all?) of Apple and Microsoft's "new and shiny." For every new thing you decide you depend on in the OS, you're leaving users behind, and making your code more and more dependent upon Apple's latest whim.
Which, again, you can do, absolutely -- but you don't have to.
Almost every time I see some application that "requires" some fairly late version of an operating system, I think dark thoughts. There are few things, particularly things that are focused upon new features, where it is likely reasonable. But mostly... not. Mostly it's just thoughtless development where the user takes a back seat to... let's face it: "shiny."
Depends on where you live. Here in Montana, we have 120v AC plugs at most parking spaces where employees park. These have been used to run our engine block and battery heaters -- otherwise, on our -40 days, you go back out after your 8 hours of wage-slavery and your vehicle is not very likely to start unless you've come out several times and warmed it back up (and on windy days, even that doesn't work.)
So here, slow-charging, at least, should be available to some extent. I do wonder what the combined load of block/battery heaters + battery charge will be; related, if you can tell the vehicle to limit the charge rate to, say, 10 amps; and how employers will feel about providing same... but they'll figure something out. They'll have to.
A lot of people here have garages (same reason... parking outdoors can be rough in winter) and it seems to me that the sensible time to charge regular-use short-to-medium distance use EVs is at night anyway.
Looking forward to it, however it goes. I'll keep my 4WD pickup for the really nasty weather and transport of heavy stuff, but EVs are my target for most driving and the Tesla looks like what I want at the moment. Assuming, again, that they can produce enough so I can actually buy one.
You forgot to subtract the EV-hate constant from all your numbers. Fail.
"for free" meaning, you paid a hell of a lot more for your vehicle and part of that went for supercharger use.
Funny use of "for free", but okay.
Me, I'm looking forward to my "not for 'free'" electricity consuming Tesla, if they can just get them built. Breath-holding does not seem to be called for here.
That's... an interesting opinion. I think there's likely a considerable amount of truth in it. I'd mod you up for it if I had points today.
Also, it's worth noting that they made it the law that your phone HAD to give out location information. 911 and all that.
So:
step 1: force phones to give up location
step 2: claim that because phone location is given up, it's not subject to the 4th
They aren't neutered. They simply are able to deadlock. Doesn't mean they will, or have to.
There's no set size for the court. It's been larger, and it's been smaller. It's been even numbered and it's been odd numbered.
Doesn't much matter anyway. They do whatever they want. We're long past them actually paying any attention to the oaths they swore.
The fourth amendment says nothing about "third parties." Not one word.
This is just more judicial activism continuing to bite the citizens in the posterior.
Reasonable = probable cause, oath or affirmation, description(s) of place to be searched and item(s) to be seized, which allow for a warrant to be issued. Anything else = UNreasonable.
Anything the justices say to the contrary is in direct violation of their oath of office.
Not that there's any surprise in that.
er... yeh. :)
If you go down this road carelessly, you'll end up with an ultra-wide bus. So consider server back door operation, as this is generally an underutilized port. Make sure you employ Logical Unit Bus Expansion tech in both cases; otherwise bus errors are much more likely to occur. Note that as with all bus expansions, you must arrange for the bus impedance to be low; this requires low resistance, and also, if capacitance is relatively high, you'll find that although the bus will work to some degree at low rates, data will be lost trying to charge surfaces that exceed the capacity of the bus driver. Should you have to deal with a high-capacity system, large auxillary drivers can compensate for this. In my designs, I have found that stocking the right components tends to skirt problems up front WRT driver installation procedures, and with the drivers themselves, as full access to the bus is available without having to completely strip the hardware to the chassis. Please note that installations should always undergo vibratory stress testing under full load as a precursor to customer acceptance. This also tends to increase long term bus compliance.
Not to worry. I'm used to it.
How to take your N world country and turn it into a N-1 world country: Restrict the Intertubez.
Way to walk it back.
...the first comments removed will be any anti-microsoft comments. So much for the year of linux on the desktop...
Bleached coral is not always dead. Bleaching is caused by expulsion of the symbionts with the intent of acquiring new symbionts more able to produce nutrients under the current conditions.
Death occurs in situations like this only if symbionts do not arrive and the coral starves.
The media tends to overlook the details. As usual.
"Just" -- I don't think that word means what you think it means.
You left off:
o horribly over-commit available bandwidth resources so 30/5 jerks and stalls like a horse being driven over a cliff
Wahoo. And stuff.
No question about it. I sleep well, though. :)
Features are one thing. That's a perfectly valid way to sell a new device.
However, bugfixes during a product's normal lifetime are another thing entirely.
I am of the opinion that if you sell a piece of software, first, you should specify what it is you are selling it to do, and the environment within which you are claiming it will do these things. Which we can take, at least at the moment, as "the feature list." If the software does not do what you said it would do, or work in the environment you said it would the way you said it would, then I believe you have two, and only two, valid ethical choices:
o Fix it
o Refund the customer's payment
Similarly, if the software does something harmful that you failed to notify the buyer of before the sale, I believe you have two, and only two, valid ethical choices:
o Fix it
o Refund the customer's payment (and depending on your original claims, there may be liability as well.)
I think the mindset that software producers have been allowed to develop that they can leave a trail of broken and never-to-be fixed software behind them, while proceeding forward on the proceeds made from said broken products, has led to a serious downside: that we very rarely actually end up with working software. Instead, we get new software. It's... shiny. Those new features glow like a fancy new chrome bumper. But because it's not actually fixed, it's new, it often (very often, especially in the case of operating systems) causes other things to fail where they used to work just fine, because slipped in their with "new features" are often "yeah, we changed that, it's NEW!" Whereas, if, for instance, Apple had actually fixed the printing bugs for OS X 10.6.8, then those things that were working in that environment otherwise would then have had access to printing functionality as originally claimed by Apple, and stability, reliability and functionality would be optimized.
An example I am familiar with: If you stick with OS X 10.6.8 on some Mac Minis, then you suffer with a permanently broken printing system in some respects with some CPUs (core duo, IIRC), and if you also depend on 10.6.8 features/capabilities (such as PPC emulation, for instance) then 10.7 and beyond are not an option, therefore you are permanently broken.
This is just an Apple example. I know Microsoft left the Windows file dialog broken for multiple selection in various releases of Windows, never fixing the problem. To this day, if you select too many files in the most-fixed version of some Windows releases, you'll experience bugs. Another: in some versions of Windows, the font rotation API went clockwise, and in others, it went counter-clockwise. Instead of actually fixing it, Microsoft had us special-case the OS by version. I feel reasonably sure experienced Linux users could supply similar examples in the various commercial Linux distributions where to get a fix, you actually need a shiny new version of Linux, rather than the version you already have, actually fixed and still 100% compatible otherwise.
What I'm trying to get across here is that I think that we, as users, should do a more thorough job of holding developer's feet to the fire when they give us broken stuff. Speaking as a developer, I try to live this; if bugs are reported to me during the life of a commercial product, then that product's life does not end until those bugs are fixed. I've been doing this with my freeware, also. And -- at least for me -- I find it very satisfying to bring the product as close as possible to what I claimed / thought it was in the first place. I don't like bugs.
Apple's the company I am most familiar with as I've been using OS X for quite a while now. And I can tell you that my feelings about Apple's choices WRT bug fixes and leaving broken crap behind them are not in any way positive, respectful, or satisfied.
We can do better. I actively try to do better. And I don't have hundreds of billions of dollars in the bank to back me up, either.
Wait until there's actual AI software (as opposed to the LDNLS people are mistakenly calling "AI" now.) Then we'll have intelligent, conscious... numbers. That no one can own (hopefully, we've learned our lesson on slavery.... okay, I'm being way too optimistic here, but roll with it.)
Now numbers can vote, own property... Instead of a digital artwork's "owner", you could end up its "guardian."
Perhaps we shouldn't go with "it's a number" after all. :)
As a parent, are you not old enough (informed enough should be the metric, but our society is bewildered about age) to decide if your kids can use the device?
Oh, right, parenting. Not allowed to do that any longer, my bad. "It takes a village" (to pillage your informed personal and consensual choices, not to mention parenting.) Of course you're not old enough. We'll decide that for you. Move along. Move along.
There are indeed. However, those limits are moving constantly, and in the less-limited direction. While worker costs are steadily increasing on multiple fronts even without wage increases.
Don't assume automation won't get to a point where it can't do what's required in a job that is essentially repetitive in nature. That's an extremely poor bet. Not only is more competent, acceptably abled automation going to happen, it's going to happen fairly soon in the fast food industry, where many franchise instances create significant financial motivation for automation manufacturers -- two to three years is my estimate.
All wages at $5 an hour do is make the rest of us support the workers via the social safety nets.
And if you take the social safety nets away, then you have people who are earning $200/week for 40 hours labor.
That means no medical care, rent is impossible to pay in many circumstances, etc., etc., ad nauseum.
Even as it stands now, we subsidize those corporations with our taxes; that's the only thing that makes the wages they pay now survivable in any real sense of the word in any urban environment. Small town or country living, maybe you can make some kind of sane go of it for less than $10/hour, but it's definitely the exception, not the rule.
For McDonald's and the like, when the cost of functionally adequate automation falls below the cost of employment, they're going to move to automation. We either figure out how to handle the consequences ahead of time, or we take the beating when it happens without any fallback position. My guess is that it will probably be the latter, inasmuch as politics-as-usual always seem to target only the nearest term headlights-in-the-tunnel.
Also... speaking now with my AI researcher hat on: I think it's a slam dunk that the automation that will suit the fast food service industries is going to arrive very, very soon. With other service industries soon to follow. This problem is basically on our doorstep right now. Most people fail to see it because it represents a paradigm shift - things will be as they have never been before in history, and it's just very difficult to imagine fundamental changes in one's worldview that have no precedent.
Grab the popcorn and lock your doors. Show's going to start shortly.
We're not talking about the same things. I never said services don't cost money, or that he should be free of taxes.
I said that more than 2x as much of your income goes to taxes.
Which is precisely correct.
These are the facts behind the argument that corporations should not pay taxes. When they do, they just build it into the product, and YOU pay the taxes. You don't get any more product. You just pay a higher price.
The plumber, same thing.
if that's over your head, I'm sorry.