I'd say Chaotic Neutral with Evil tendencies. The heart of Anonymous is chaos: no visible structure, no weak points, just lots of individuals that occasionally cooperate. They are a source of punishment much more than reward, but the targets that they punish are usually violators of some sort of ethical boundary (I'd say Neutral with occasional Good depending on target, but every DM has their own definition of alignment anyhow). The "for the lulz" motivation for many members is very selfish, and selfishness is squarely on the path towards Evil (personal gratification without regard to the expense/effects on others).
One of the few appropriate examples of Chaotic Neutral. Most attempts (even the 2nd edition Player's Guide, IIRC) end up depicting the alignment as Chaotic Stupid. Maybe it's an indication that Law/Chaos applies to a community rather than an individual. In any case, it's certainly better that Wizards of the Coast's latest alignment interpretation, where the bad guys are either Evil or Really Evil.
If I ever again run a customer facing business, I'm going to put a field on all paperwork for SSN. Anybody who willingly writes it in will get smacked upside the head. Hard.
Please do. While many people will assume you are calling them stupid and get offended, there will be some that appreciate the educational experience.
Though, if you can build me a nice automativ dynamic expander for all the horribly-loud stuff I already have... That'd solve the problem equally well.
Not possible, the damage has already been done. The horribly-loud stuff has been quantized and clipped. Any expander will upscale the quantized values and require interpolation, and probably shift the result and require extrapolation to deal with clipping. Both of these are ultimate fabricating guesses about the original sound waves. That's actually one reason why some audiophiles prefer vinyl copies of otherwise-brickwalled recordings: forcing an analog representation of the signal will naturally smooth clipping (since the medium isn't manufactured with atomic-level precision). But it still loses information; it's just a more "pleasant" approximation.
Largely because those that actually have the time are independently wealthy.
Right, unlike all of the poor sodding masses that don't have any time to watch TV or anything like that. Those rich snobs and their hobbies, stuff them all!
Yes, you are. The point is that Microsoft's environment does allow forward-slash "/" as a path separator, which is POSIX. However, precedence in the MSDN documentation is to continue using backslash "\\" (or r"\" in python or @"\" in C#). So sometimes people end up jumping through imaginary hoops:
I'd also like to point out that cmd.exe will only tab-complete paths if backslashes are used, further emphasizing that MS has no interest in encouraging developers to switch to forward-slashes.
IMHO, and perhaps veering slightly off-topic, "real men" are secure enough in their own virility that they don't have to resort to acts of reckless bravado to prove how "manly" they are <shrug>
That may be true, but "Real Men use white iBooks" has less flair than "Real Men reboot UNIX servers all the time for no good reason and then kick the Windows admins with their Energy Legs."
Originally the meeting was scheduled at 14:00 in Frankfurt and 13:00 in the UK. Now UK changes their time. The calendar thinks it's scheduled at 14:00 in Frankfurt and 14:00 in the UK. But perhaps that's not the desired result; perhaps it should have followed UK local time and been scheduled for 13:00 in the UK and 13:00 in Frankfurt. There's no way the calendar program can know.
The calendar program cannot read minds; the problem you highlight is universal. Even if everybody writes the meeting date/time down in a sheet of paper in their wallet, they'll still need to reconcile when the time zone definitions change, because the original assumptions (relative timezone offsets) have changed. Honoring the time zone of the meeting organizer is the most correct solution, because that is representative of the social structure.
If there's a conference call between your UK office and your Frankfurt office, and the local time on one side or the other changes, there's no way the calendar software will know which is correct.
If you're going to store a local time-of-day value instead of an epoch, it would be silly to do so without a timezone. So if the record is created by someone in the Frankfurt office, it will read something like "14:00:00 CET". This is not a problem.
It's not a bug, just a nationalistic preference. So who gets to decide whether it should be changed or not?
Sounds like a bug to me; and if it's not, a maintainer can point out exactly why it's not included (population too low, too near to a much-more-noteworthy city, fear of blancmanges, etc.) If individual capitols of the USA are included (regardless of population), that sets the bar for individual sub-national capitols in other nations. TBH I don't know exactly how the UK is structured, but "Capitol of Scotland" sounds like a no-brainer.
You can get pretty far without accounting for leap seconds in many programming gigs. For time intervals, odds are that the interval either contains no leap seconds, or is large enough that the error introduced by the leap second is incredibly small. For absolute timestamps that get formatted into wall-clock time for human consumption, nobody really cares about a handful of seconds.
If anything, it has made things simpler: less language "burrs" (e.g. / now does float division...)
That particular "burr" I think is something that divides people. While it does make certain generic functions simpler, it's arguably less intuitive for some large user-bases:
whole-number math (i.e. kids and certain branches of mathematics): 5/4 == 1 remainder 1, or 1 + 1/4.
programmers who have ever used integers before: 5/4 == 1 due to truncation. Also—and this is very important in a culture of abstractions—this is how hardware works.
...eliminating the need to stick float() on one argument...
That was always wrong. IIRC the correct way to get generic floating-point division pre-Python3 is "x * 1.0 / y". It up-converts native integer types without down-converting complex or user-defined numeric types. Still ugly, but workable.
So with Python3, one use-case was made simpler (remainder-free division: x*1.0/y) and the other use-case was made harder (integer division: x//y). It didn't make the language "simpler" as a whole.
Re:Another great Python 3.x series release
on
Python 3.2 Released
·
· Score: 1
2) Refactor/redesign to reflect the new requirements and as much of the future you can predict from this new position. Maybe you can do this while keeping backwards compatability, and maybe you can't.
If you can't keep backwards compatibility, then you're not actually refactoring. In the context of this discussion, the changes being discussed are most definitely not refactoring. Please don't dilute the term, or it'll have less power when we need to argue it to our managers.
Re:Another great Python 3.x series release
on
Python 3.2 Released
·
· Score: 1
Physical manufacturing can't be compared fairly. Every widget created has a cost, which reduces the relative cost of designing a new type of widget (and gets amortized over time). With software, the cost of designing a new type of widget (porting software across OSes or language revisions) is pretty much the entire thing.
Plus, your analogy is off. Comparing jet and piston engines is akin to comparing different programming languages, not different versions of a programming language. The Python folks decided to make their version so incompatible that some people in this thread are arguing that they should be treated as different languages entirely. That's like a piston engine manufacturer upgrading its piston engine production in a way that requires new parts, fuels, etc. and still calling it a piston engine. It's bound to confuse and upset the expectations of some consumers and suppliers.
That's a good point but look, the bottom line is you can achieve the same thing without BCC or CC and just deliver requirements to your devs outside of the conversation with clients
I think we're dereiling ourselves... the bottom line in this thread is that BCC is not dead, because are still many legitimate uses for it.
I dunno...that's certainly not a malicious use of BCC, but what do you do when the client responds with a clarification or correction? You have to remember to forward that response to the BCC'd engineer. CC would be much more useful.
As a project manager or customer-relations manager given this scenario, your priority should be preservation of your engineers' privacy. It's better to guarantee that with BCC—with the added cost of remembering to forward replies appropriately—because that's your job. A disclaimer or policy can always be ignored.
Its only use as far as I can tell (I welcome counter examples) is to enable political bullshit.
Counterexample: A large organization has an IT staff that is shared across several autonomous (and potentially competing) business units. Some member of the IT staff must now send a message to all business units about a particular piece of technology that is considered "sensitive" (i.e. it's exposing too much to even know who uses it).
Solution: email the IT group itself and other "shared" resources. BCC all business units, with a comment in the email to that effect. Privacy between business units is maintained. "Reply All" keeps the discussion isolated to IT plus a single business unit, where it belongs.
Yes, you could use some sort of mail-merge to send the same email out to each group independently. So BCC and Mail-Merge have some overlap in the functionality they provide. That's OK.
I mean, keeping poisonous substances out of reach of a 3 year old isn't coddling them, it is preventing accidents that are easy to prevent.
Nobody said otherwise. I believe "poisonous/caustic liquids" falls under the same category as "hot oil", not "hot metal pr0n". It's a lot like Q learning (or other reinforcement techniques). An event that kills the child will prevent it from learning. An event that damages the child either permanently or for an extended period (lost limb, helmet-less head injury on a bike, etc.) might be a learning experience, but the cost is too high. An event that hurts the child for a short period of time (after which the child fully recovers, of course) is perfect.
Pull your money out of the stock market and convince all of your friends to do the same. Find a way to invest your money in a way that you feel is proper. If enough people reject the market in its current incarnation, change will be forced. If not, at least you know that you're doing what you can.
Just don't get upset when many people disagree with you. We all choose our own poison.
I considered arguing with your example on the basis of the presence of floating-point (prices are discrete - any sane market uses fixed-point integer arithmetic). However, since you did not provide a complete running program I have to admit that it's possible that your code is C++ and rand() is a function that returns an object, and the object's member function operator+(float) simply returns *this as a red-herring to confuse the interns.
Slashdot Mirror
I don't need a computer to tell that I'll never make that saving throw...
I think homeowner's insurance trumps a house fire. In any case, CDs are the least of my worries at that point.
I'd say Chaotic Neutral with Evil tendencies. The heart of Anonymous is chaos: no visible structure, no weak points, just lots of individuals that occasionally cooperate. They are a source of punishment much more than reward, but the targets that they punish are usually violators of some sort of ethical boundary (I'd say Neutral with occasional Good depending on target, but every DM has their own definition of alignment anyhow). The "for the lulz" motivation for many members is very selfish, and selfishness is squarely on the path towards Evil (personal gratification without regard to the expense/effects on others).
One of the few appropriate examples of Chaotic Neutral. Most attempts (even the 2nd edition Player's Guide, IIRC) end up depicting the alignment as Chaotic Stupid. Maybe it's an indication that Law/Chaos applies to a community rather than an individual. In any case, it's certainly better that Wizards of the Coast's latest alignment interpretation, where the bad guys are either Evil or Really Evil.
But I don't want any Tolkien!
Please do. While many people will assume you are calling them stupid and get offended, there will be some that appreciate the educational experience.
Sucker. I'll be drinking half malt scotch, quintuple-distilled.
Not possible, the damage has already been done. The horribly-loud stuff has been quantized and clipped. Any expander will upscale the quantized values and require interpolation, and probably shift the result and require extrapolation to deal with clipping. Both of these are ultimate fabricating guesses about the original sound waves. That's actually one reason why some audiophiles prefer vinyl copies of otherwise-brickwalled recordings: forcing an analog representation of the signal will naturally smooth clipping (since the medium isn't manufactured with atomic-level precision). But it still loses information; it's just a more "pleasant" approximation.
Right, unlike all of the poor sodding masses that don't have any time to watch TV or anything like that. Those rich snobs and their hobbies, stuff them all!
Yes, you are. The point is that Microsoft's environment does allow forward-slash "/" as a path separator, which is POSIX. However, precedence in the MSDN documentation is to continue using backslash "\\" (or r"\" in python or @"\" in C#). So sometimes people end up jumping through imaginary hoops:
I'd also like to point out that cmd.exe will only tab-complete paths if backslashes are used, further emphasizing that MS has no interest in encouraging developers to switch to forward-slashes.
That may be true, but "Real Men use white iBooks" has less flair than "Real Men reboot UNIX servers all the time for no good reason and then kick the Windows admins with their Energy Legs."
The calendar program cannot read minds; the problem you highlight is universal. Even if everybody writes the meeting date/time down in a sheet of paper in their wallet, they'll still need to reconcile when the time zone definitions change, because the original assumptions (relative timezone offsets) have changed. Honoring the time zone of the meeting organizer is the most correct solution, because that is representative of the social structure.
If you're going to store a local time-of-day value instead of an epoch, it would be silly to do so without a timezone. So if the record is created by someone in the Frankfurt office, it will read something like "14:00:00 CET". This is not a problem.
Sounds like a bug to me; and if it's not, a maintainer can point out exactly why it's not included (population too low, too near to a much-more-noteworthy city, fear of blancmanges, etc.) If individual capitols of the USA are included (regardless of population), that sets the bar for individual sub-national capitols in other nations. TBH I don't know exactly how the UK is structured, but "Capitol of Scotland" sounds like a no-brainer.
You can get pretty far without accounting for leap seconds in many programming gigs. For time intervals, odds are that the interval either contains no leap seconds, or is large enough that the error introduced by the leap second is incredibly small. For absolute timestamps that get formatted into wall-clock time for human consumption, nobody really cares about a handful of seconds.
That particular "burr" I think is something that divides people. While it does make certain generic functions simpler, it's arguably less intuitive for some large user-bases:
That was always wrong. IIRC the correct way to get generic floating-point division pre-Python3 is "x * 1.0 / y". It up-converts native integer types without down-converting complex or user-defined numeric types. Still ugly, but workable.
So with Python3, one use-case was made simpler (remainder-free division: x*1.0/y) and the other use-case was made harder (integer division: x//y). It didn't make the language "simpler" as a whole.
If you can't keep backwards compatibility, then you're not actually refactoring. In the context of this discussion, the changes being discussed are most definitely not refactoring. Please don't dilute the term, or it'll have less power when we need to argue it to our managers.
Physical manufacturing can't be compared fairly. Every widget created has a cost, which reduces the relative cost of designing a new type of widget (and gets amortized over time). With software, the cost of designing a new type of widget (porting software across OSes or language revisions) is pretty much the entire thing.
Plus, your analogy is off. Comparing jet and piston engines is akin to comparing different programming languages, not different versions of a programming language. The Python folks decided to make their version so incompatible that some people in this thread are arguing that they should be treated as different languages entirely. That's like a piston engine manufacturer upgrading its piston engine production in a way that requires new parts, fuels, etc. and still calling it a piston engine. It's bound to confuse and upset the expectations of some consumers and suppliers.
I think we're dereiling ourselves... the bottom line in this thread is that BCC is not dead, because are still many legitimate uses for it.
As a project manager or customer-relations manager given this scenario, your priority should be preservation of your engineers' privacy. It's better to guarantee that with BCC—with the added cost of remembering to forward replies appropriately—because that's your job. A disclaimer or policy can always be ignored.
Counterexample: A large organization has an IT staff that is shared across several autonomous (and potentially competing) business units. Some member of the IT staff must now send a message to all business units about a particular piece of technology that is considered "sensitive" (i.e. it's exposing too much to even know who uses it).
Solution: email the IT group itself and other "shared" resources. BCC all business units, with a comment in the email to that effect. Privacy between business units is maintained. "Reply All" keeps the discussion isolated to IT plus a single business unit, where it belongs.
Yes, you could use some sort of mail-merge to send the same email out to each group independently. So BCC and Mail-Merge have some overlap in the functionality they provide. That's OK.
Wow, you create small startup companies when you check your email? That's godlike!
Nobody said otherwise. I believe "poisonous/caustic liquids" falls under the same category as "hot oil", not "hot metal pr0n". It's a lot like Q learning (or other reinforcement techniques). An event that kills the child will prevent it from learning. An event that damages the child either permanently or for an extended period (lost limb, helmet-less head injury on a bike, etc.) might be a learning experience, but the cost is too high. An event that hurts the child for a short period of time (after which the child fully recovers, of course) is perfect.
Pull your money out of the stock market and convince all of your friends to do the same. Find a way to invest your money in a way that you feel is proper. If enough people reject the market in its current incarnation, change will be forced. If not, at least you know that you're doing what you can.
Just don't get upset when many people disagree with you. We all choose our own poison.
I considered arguing with your example on the basis of the presence of floating-point (prices are discrete - any sane market uses fixed-point integer arithmetic). However, since you did not provide a complete running program I have to admit that it's possible that your code is C++ and rand() is a function that returns an object, and the object's member function operator+(float) simply returns *this as a red-herring to confuse the interns.
Dammit, you really had me going!