Google Customer: Wait, you said "no based on privacy rights" not "no based on that you didn't actually record that information"
Google:...
Actually, it's more like:
Google: Um, yeah. We kept telling you "it's not the usually Yada yada." You don't like it? That sucks, but we told you we were doing it.
Customer: Oh. But, what about don't be evil?
ACLU: Constitution!
Google: One at a time, fer crying out loud. We're still not evil, and the Constitution has nothing to do with it. Next question!
Feds: Um, records?
All: Oh, do shut up.
Sometimes I fastasize abotu getting the SW field tech and HW field tech at the same time, and locking them both in a dis-used closet with the box until it works. Probably, I'd open the closet months later to find two stinking corpses and the server whirring with quiet malevolence.
To paraphrase, utopia cannot begin until the last SW field tech is strangled with the entrails of the last HW field tech.
There's one. Many financial sites are like that, as well as a few more i've seen. I love firefox, but it is still lacking in some CSS2 areas.
There's something gutbustingly hilarious about saying "can't use alternative browsers for IE-only sites" and then going on to complain about a few CSS2 issues in Firefox.
Granted, I don't know a browser that perfectly handles all of CSS2, but IE is one of the worst offenders. display: fixed, and most of the pseudo-attributes completely fail under IE. Not to mention the ongoing legacy of a broken box model in older versions (that simply will not die, and that MS has never patched). The box model! Not like it's at all essential to design or anything.
4) While a great idea, this technology is pretty expensive and tricky to implement, at least from what I've seen over the past five years. When companies implement it, callers totally love it, and in theory, it reduces agent talk time. But, getting companies to understand that sort of thing isn't easy.
Refering to the "enter your data, once, not have the support monkey demand it again" idea. Honestly, usually "reduces agent talk time" is a really excellent point with most companies. And most call-center level PBX systems include a reasonable amount of CTI these days. Honestly it should come down to:
"Listen, you can pay me a few grand right now to code up a little dingus that'll pop up everything we know about a caller when their call gets to an agent, or you can burn a few grand a month on phone time, and lost revenue from people who didn't get through because your agents spend close to half their time getting all this information from the caller again." Really is a no brainer.
While I concur with most of the other suggestions here, I've got a few more fish for the fire:
Modern Art. Excellent abstract game for 3-5. Plays well with 3, 4 or 5 players. Players are running modern art galleries. The art has no inherent value, only it's future value based on how it sells now. Nonetheless, you have to bid on each piece. Very nice.
Titan: The Arena. Eight monsters battle in an arena over five rounds. Players bet on which ones will survive. The earlier the bet, the more its value.
funagain.com more games than you shake a stick at. Used and out of print, too.
OK, so UML editors are now able to spit out XML. That makes the concept a bit more usable. Now we have something to grep.
Honestly, with exception of the pricey (but apparently bery usable) Rational products, most of the UML editors I've worked with (not counting Visio, which shouldn't come as a surprise) have produced some form of XML document. None of them are exactly human parseable, though. It is nice to be able to CVS the whole thing though.
Perhaps, but add 'test-first' development with unit tests to the mix and you've got an executable spec.
I think we both agree that test-first is an excellent paradigm, and I quite agree that a good set of unit tests help round out any specification. But the fact is that not having some kind of a diagram makes it especially difficult to understand the overall structure of any significant project.
his continual syncing between code and pictures becomes burdensome at some point. Unless you can use UML to completely genereate your code this will be a problem (I realize that this is now possible to some extent, but not completely.
Actually, a historical goal of UML was that it be generated from existing code (i.e. the other way around). The big feature in the UML arena right now is what's called Round-Trip Engineering, which is marketdroid for being able to make changes either in code or in diagram and then sync it up safely.
Basically, there are two cases where UML is most useful. The first is large projects with several developers, since it's very easy to show someone a diagram and let it Just Make Sense, or be able to express overall structural proposals quickly.
The second is starting any project bigger than a dozen objects. Mapping everything out ahead of time can mean big savings in refactoring later (which takes more time even in prototype), and the dicipline inherent to UML means that you can be confident that a well structured UML representation will result in good relationships in the eventual code. Then you've got a rough document of the eventual result that can be updated if it's needed. Otherwise, a literate program with good tests can sometimes be its own specification.
Mainly because it's a whole lot easier and more powerful to describe a circuit with an HDL. You don't have to draw all those wires to connect everything.
While that may be so, for software design of any significance, you're going to need to express relationships that will be difficult to predict a priori. Using a design language might be easier to produce, but it's certainly no more expressive of the overall design than a diagram.
Another reason that schematics were abondoned is that it's a lot easier to parse text than graphics. The UML promoters should take note.
Gee, I'd wondered why there was this whole XMI thing that was running around the UML editor industry. Seems like it's not just text but XML, so there's not even the trouble of writing their own parsers. How novel! For humans, on the other hand, it's much easier to parse the graphical representations of UML, from the rough conceptual level of "so how does this work" all the way down to the specification level, thanks to the rigidity of UMLs definitions. (Granted, yes, a set of UML diagrams does not a spec make, but you need very little in the way of supporting documents to round out a very usable spec.)
The answer is to program at a higher level of abstraction. This might mean chosing a higher-level language to prototype in (I like prototyping in Ruby) or it might mean using techniques like state machines, for example.
If that's your answer, I'm not entirely sure you caught the question. While yes, I completely agree that a Ruby prototype is an enjoyable and useful execisize, and that your programs might even be completely literate in Ruby, they aren't a substitute for diagramming (or spec) of some kind.
A prototype and a spec are two completely different things. They each have their place, and they aren't wisely exchanged.
That's not ambiguity. Ambiguity is saying one thing which could mean several things; according to your assertion, case-sensitive languages have more than one way (Bar vs bar) to say the same thing.
...just like in the English language. It's more natural to me to expect Bar, bar and BAR to be the same variable than not. I think it's ambiguous to have two different variables which, read in English, are the same word.
Okay, that's just fuzzy thinking. "bar" and "Bar" in English have vastly different meanings. One is any length of metal or place of business that sells alcohol. The other is either the same, but beginning a sentance, or a specific and important example of the same. And "BAR" is short for "Browning Automatic Rifle." And that's in sloppy, messy, subtle and ambiguous natural language English (as very distinct from "english".)
As such, it's completely reasonable to make a compiler case-sensitive. As a programmer, I mean very different things by aVariable and AVariable.
I find well-used capitalization improves the human readibilty of code. The last place I want sCriPt-kIDDie caps-slip is in decent code. If a language constraint makes that difficult, I applaud it.
The strongest rationale I can see not change an existing language is that it would break a wealth of existing code. The extension of that reasoning is that a new language should tune its sensitivity to it programmer audience. If you're writing a language aimed at existing C programmers, make it case sensitive. If you're aiming at some other group, perhaps case insensitive syntax is acceptable.
I'd like to emphasize how difficult it is to not think (and write) "professional programmers" for "C programmers" and "VB hacks" for "some other group." But I wouldn't want anyone to think I was biased.
If by mangled you mean "extremely different." Thanks for the link, which was interesting, but I think there are significant differences between a restructured income tax and a sales tax.
Also note that the sales tax depends on an eventual reimbursement, so a poor family would have to struggle under the burden of a regressive sales tax until the reimbursement cleared. There's a big difference between a dollar today and a dollar six months from now.
Quick aside (because we're already drifting from topic):
Whenever the idea of a flat tax comes up, the counter argument is always (and correctly) that at the low end of the income spectrum, the remainder of a flat percentage is less than survivable - or at least, provides for a level of survival that is disgraceful in a country as wealth as the US is.
There's also the (slightly disengenious) argument that in lower income ranges, there's less time to figure out how to represent your taxable income as being smaller than it might otherwise appear, less room to build tax shelters, and certainly no money to pay someone else to do it for you. (On a related point, one might argue that the existence of tax accountants is a rebuke of a corrupt tax system. But that would also be more than a little disengenious.)
That said then, why does no one ever propose the following. Set a limit to how much money it takes to live. Define it seperately from the rest of the tax code, because there would obviously be adjustments for marriage and domestic partnership, children, etc. Simply impose the restriction that the limit is a cost of living, and that apart from reasonable variations, it applies to everyone.
Now, apply a flat income tax on any income above that level. If you press the limit up, and drive the tax rate towards 100%, you work towards a kind of socialism, which obviously is not an advantage. But at present, the richest Americans pay 50% of their declared income, so that's obviously not what we're looking at.
So apart from the issues of twisting and corruption, where's the harm in this semi-flat income tax?
Obviously the squirrelly part comes in the protection limit, but we already presume to individually adjust taxes based on exemptions, so what else is wrong with this scheme?
Copyright infringement is word-for-word copying of exact text or note-for-note copying of music, etc.
Not so. While the reverse is true, copyright also covers (amongst other things) the production of derivative works. The question of "what's derivative?" is perfectly valid, and any valid defense of Underworld hinges on the argument that it isn't a derivation of the World of Darkness property. Either crucial elements of Underworld were developed in ignorance of the White Wolf World of Darkness (ideally, by predating them), or whatever similarities do exist are different enough to be considered Fair Use inspiration rather than infringing derivation.
Now, obviously, IANAL, but I have and have had cause to be very interested in copyright, and the time to investigate.
d20 is fine for AD&D, but a lot of roleplayers (self included) feel that a system should match it's setting - that, yeah, I huess you can use any source for any game, but why? AD&D is at heart, and still, a wargame with heroes. Nothing says you can't actually roleplay, but the system is built around tweaking.
So it's an unfortunate trend when a number of games whose systems matched their tones very nicely (most tragically: Call of Cthulhu) are moving to a d20 system, and sacrificing both a good mapping of system to world and a good match in tone between system and setting in the name of drawing more players.
Actually, by suggesting that the mass of a neutron is the sum of the masses of an electron and a proton, you're dodging one of the really fun little divergences in subatomic physics. There's actually a really tiny difference between M(n) and M(p) + M(e). Something like three or four orders of magnitude smaller than an electron, but the difference is there.
His name is Neutrino. His mass is real, but he is not.
Mr. Strigl said the timing of the announcement was related to a decision earlier this month by a federal appeals court rejecting the industry's argument. The wireless companies contended that the portability requirement was not necessary to protect consumers. "The case was lost in court and now it's time to get on with providing customers with what we believe they want," Mr. Strigl said in an interview. "We're wasting too much time on this."
I love the Google Language Tools (Translate: Corporate Swine to English):
"We've finished repositioning, and as the biggest wireless carrier, we can now afford this change better than anyone else. So by pretending to buckle like a belt, we are in fact going to use the full force of the United States Government to sweep most of our minor competitors out of the field. The other big boys can afford it, but we can not only afford it, we can buy up the corpses of the minor players who are going to be creamed trying to comply. We'd thank the FCC publicly, but we don't want to look like a Bond villian in front of our new, larger customer base."
</CYNICISM>
Still, it'll be nice not to be locked to a single carrier by a phone number. If only there'd still be a choice of carriers once this goes into force.
I think I have to disagree. Restricting hacking to technical devices is too limiting. But, I wouldn't say that merely recovering lost arts is hacking.
But, when I go back to skills that are being swiftly replace, I do so for one of two reasons: I want a thing that no one else makes, or the modern variant is unacceptable.
Example one: I wanted a desk, so I took up furniture carpentry. Because Ikea doesn't make desks that are worth a damn, and no manufacturer was going to produce the marvelously functional desk I desired. I think the four sided over-desk shelves is the part that's beyond mass appeal. Granted, the reason I take up a skill never turns out well, but as I improve, I remake them. Not as easy as recompiling a minor version upgrade, but it gets me out of doors. This kind of "old world" skill, I take up so that I can add to the realm of what exists, or to discover new techniques, etc.
Example two: I've been very disturbed by the trends I've seen in modern razors. I hate the goo strips, Mach3 heads open new nostrils in my cheeks, and a basic, non-swiveling, non-goo disposable is going to be sharp for about three shaves. So, without any desire to improve on it, I've taught myself (with surprisingly little blood loss) to shave with an open razor. To a great deal I feel vindicated in the decision, since the resulting shaves are vastly superior.
I feel like I could clearly draw a parrallel in either case to my motives for hacking. I learn Unix derivatives because no one's really done it better yet, even though they want to charge me outragous prices for two and a half shaves. I learn a horde of programming languages and command line tools and design skills so that I can make my own.
I think the mistake here is assuming you have to explain it. Consider Tim Robbins Lost In Space (aka Red Planet): the science goes right out the window, and the majority of the audience says "wow, how tragic," not "hm, orital mechanics is beyond me, uhuh."
You're real problem is not explaining things - I mean, we understood a year to be a different length in The Dark Crystal for Henson's sake, and that was just muppets. It's selling the setting. A science fiction reader will buy the whole toroidal gas cloud once it's explained. But without explaining, how do you sell the basic facts of the setting: atmosphere in orbit? Maybe a rocket-truck from way out where you can see the whole smoke ring way in past little people floating in air to a Tree? Solve the selling question and the movie just rolls along. Well, that and financing yet another not-frame-untouched SFX extravaganza.
First and absolutely foremost: an FSM is an adstract concept born of graph theory. A statechart is a diagram of an FSM, which complies to a rigorous specification for what each notation means.
The statechart spec adds a few semantically trivial notations (i.e. they can be easily translated into standard digraph style FSM), which are nonetheless extremely useful for presenting clear, easy to understand diagrams.
Most of those additions have been mentioned already (e.g. nesting) but there are also guard conditions (i.e. transition if X except if y), and indications of entrance, presence, and exit behavior. Very handy for describing behavior.
Sorry to disagree, but no. The Von Neumann cycle doesn't address what the commands do, only how to go through them. Consider a load/store architecture, where there are explicit load and store instructions and everything else works from registers only. Then everything is a bus control instruction.
Point being, the "store" step you're positing occurs in the context of executing the decoded instruction.
Sure, it's important to store your results, but it's also important to load your operands, and the Von Neumann cycle doesn't address either operation.
The basis of almost every digital computer is a basic cycle, viz:
Load the next instruction from the memory location indicated by the program counter.
Decode the instruction.
Execute the instruction.
Some implementations add a step between 1 and 2 that says "increment the program counter" and leave jumps up to specific instructions. Others associate program counter changes with every instruction (i.e. jumps go to somewhere specific, every other instruction also implies PC++.)
There's nothing more to Von Neumann machines. They are unrelated to finite state machines or Turing machines, except that every Von Neuman machine can be modelled as a Turing machine. The difference is that a Turing machine is a mathematical abstraction, whereas Von Neuman machines are an architecture for implementing them.
Whoo hoo. And yes, I am a computer scientist. Or maybe a cogigrex.
Please report immediately to your nearest mental health facility. Repeat what you've posted here, and calmly accept any medication which will be rapidly and firmly administered. Optionally, advise the mental health professionals and/or pharmacutical despensories you contact of all mind altering substances presently at work in your system.
Cuz, cus, that movie is fucked up. Cannot say it strongly enough. Had cause once to compare it to Urotsukidoji, and the DVDA tentacle rape came out on top. I mean, c'mon. He goes after her with the drill penis! And she gets away, and then she asks him to use it! And he does. Messily! He gets his powers from jamming a ribbed metal pipe into his festering thigh wound, after being hit by a car!
I mean, if I wanted postwar analysis of the dehumanization of our culture in black and white by a former Axis power, can't I just watch Metropolis. Please, pretty please? I'm begging you, I'm groveling, not the 50 hoursepower drill phallus! Have mercy!
This product contains copy-protection. The Attorney General has determined that copy-protection may be hazardous to your Fair Use. College students especially should not buy or use this product.
Slashdot Mirror
Google:
Actually, it's more like:
Google: Um, yeah. We kept telling you "it's not the usually Yada yada." You don't like it? That sucks, but we told you we were doing it.
Customer: Oh. But, what about don't be evil?
ACLU: Constitution!
Google: One at a time, fer crying out loud. We're still not evil, and the Constitution has nothing to do with it. Next question!
Feds: Um, records?
All: Oh, do shut up.
To paraphrase, utopia cannot begin until the last SW field tech is strangled with the entrails of the last HW field tech.
There's something gutbustingly hilarious about saying "can't use alternative browsers for IE-only sites" and then going on to complain about a few CSS2 issues in Firefox.
Granted, I don't know a browser that perfectly handles all of CSS2, but IE is one of the worst offenders. display: fixed, and most of the pseudo-attributes completely fail under IE. Not to mention the ongoing legacy of a broken box model in older versions (that simply will not die, and that MS has never patched). The box model! Not like it's at all essential to design or anything.
Refering to the "enter your data, once, not have the support monkey demand it again" idea. Honestly, usually "reduces agent talk time" is a really excellent point with most companies. And most call-center level PBX systems include a reasonable amount of CTI these days. Honestly it should come down to:
"Listen, you can pay me a few grand right now to code up a little dingus that'll pop up everything we know about a caller when their call gets to an agent, or you can burn a few grand a month on phone time, and lost revenue from people who didn't get through because your agents spend close to half their time getting all this information from the caller again." Really is a no brainer.
Honestly, with exception of the pricey (but apparently bery usable) Rational products, most of the UML editors I've worked with (not counting Visio, which shouldn't come as a surprise) have produced some form of XML document. None of them are exactly human parseable, though. It is nice to be able to CVS the whole thing though.
Perhaps, but add 'test-first' development with unit tests to the mix and you've got an executable spec.
I think we both agree that test-first is an excellent paradigm, and I quite agree that a good set of unit tests help round out any specification. But the fact is that not having some kind of a diagram makes it especially difficult to understand the overall structure of any significant project.
his continual syncing between code and pictures becomes burdensome at some point. Unless you can use UML to completely genereate your code this will be a problem (I realize that this is now possible to some extent, but not completely.
Actually, a historical goal of UML was that it be generated from existing code (i.e. the other way around). The big feature in the UML arena right now is what's called Round-Trip Engineering, which is marketdroid for being able to make changes either in code or in diagram and then sync it up safely.
Basically, there are two cases where UML is most useful. The first is large projects with several developers, since it's very easy to show someone a diagram and let it Just Make Sense, or be able to express overall structural proposals quickly.
The second is starting any project bigger than a dozen objects. Mapping everything out ahead of time can mean big savings in refactoring later (which takes more time even in prototype), and the dicipline inherent to UML means that you can be confident that a well structured UML representation will result in good relationships in the eventual code. Then you've got a rough document of the eventual result that can be updated if it's needed. Otherwise, a literate program with good tests can sometimes be its own specification.
While that may be so, for software design of any significance, you're going to need to express relationships that will be difficult to predict a priori. Using a design language might be easier to produce, but it's certainly no more expressive of the overall design than a diagram.
Another reason that schematics were abondoned is that it's a lot easier to parse text than graphics. The UML promoters should take note.
Gee, I'd wondered why there was this whole XMI thing that was running around the UML editor industry. Seems like it's not just text but XML, so there's not even the trouble of writing their own parsers. How novel! For humans, on the other hand, it's much easier to parse the graphical representations of UML, from the rough conceptual level of "so how does this work" all the way down to the specification level, thanks to the rigidity of UMLs definitions. (Granted, yes, a set of UML diagrams does not a spec make, but you need very little in the way of supporting documents to round out a very usable spec.)
The answer is to program at a higher level of abstraction. This might mean chosing a higher-level language to prototype in (I like prototyping in Ruby) or it might mean using techniques like state machines, for example.
If that's your answer, I'm not entirely sure you caught the question. While yes, I completely agree that a Ruby prototype is an enjoyable and useful execisize, and that your programs might even be completely literate in Ruby, they aren't a substitute for diagramming (or spec) of some kind.
A prototype and a spec are two completely different things. They each have their place, and they aren't wisely exchanged.
Ah! Finally you come to understand the Tao, grasshopper.
The saddest thing is that quoting the values of html attributes isn't required by the standard.
Okay, that's just fuzzy thinking. "bar" and "Bar" in English have vastly different meanings. One is any length of metal or place of business that sells alcohol. The other is either the same, but beginning a sentance, or a specific and important example of the same. And "BAR" is short for "Browning Automatic Rifle." And that's in sloppy, messy, subtle and ambiguous natural language English (as very distinct from "english".)
As such, it's completely reasonable to make a compiler case-sensitive. As a programmer, I mean very different things by aVariable and AVariable.
I find well-used capitalization improves the human readibilty of code. The last place I want sCriPt-kIDDie caps-slip is in decent code. If a language constraint makes that difficult, I applaud it.
The strongest rationale I can see not change an existing language is that it would break a wealth of existing code. The extension of that reasoning is that a new language should tune its sensitivity to it programmer audience. If you're writing a language aimed at existing C programmers, make it case sensitive. If you're aiming at some other group, perhaps case insensitive syntax is acceptable.
I'd like to emphasize how difficult it is to not think (and write) "professional programmers" for "C programmers" and "VB hacks" for "some other group." But I wouldn't want anyone to think I was biased.
Also note that the sales tax depends on an eventual reimbursement, so a poor family would have to struggle under the burden of a regressive sales tax until the reimbursement cleared. There's a big difference between a dollar today and a dollar six months from now.
Whenever the idea of a flat tax comes up, the counter argument is always (and correctly) that at the low end of the income spectrum, the remainder of a flat percentage is less than survivable - or at least, provides for a level of survival that is disgraceful in a country as wealth as the US is.
There's also the (slightly disengenious) argument that in lower income ranges, there's less time to figure out how to represent your taxable income as being smaller than it might otherwise appear, less room to build tax shelters, and certainly no money to pay someone else to do it for you. (On a related point, one might argue that the existence of tax accountants is a rebuke of a corrupt tax system. But that would also be more than a little disengenious.)
That said then, why does no one ever propose the following. Set a limit to how much money it takes to live. Define it seperately from the rest of the tax code, because there would obviously be adjustments for marriage and domestic partnership, children, etc. Simply impose the restriction that the limit is a cost of living, and that apart from reasonable variations, it applies to everyone.
Now, apply a flat income tax on any income above that level. If you press the limit up, and drive the tax rate towards 100%, you work towards a kind of socialism, which obviously is not an advantage. But at present, the richest Americans pay 50% of their declared income, so that's obviously not what we're looking at.
So apart from the issues of twisting and corruption, where's the harm in this semi-flat income tax?
Obviously the squirrelly part comes in the protection limit, but we already presume to individually adjust taxes based on exemptions, so what else is wrong with this scheme?
Not so. While the reverse is true, copyright also covers (amongst other things) the production of derivative works. The question of "what's derivative?" is perfectly valid, and any valid defense of Underworld hinges on the argument that it isn't a derivation of the World of Darkness property. Either crucial elements of Underworld were developed in ignorance of the White Wolf World of Darkness (ideally, by predating them), or whatever similarities do exist are different enough to be considered Fair Use inspiration rather than infringing derivation.
Now, obviously, IANAL, but I have and have had cause to be very interested in copyright, and the time to investigate.
So it's an unfortunate trend when a number of games whose systems matched their tones very nicely (most tragically: Call of Cthulhu) are moving to a d20 system, and sacrificing both a good mapping of system to world and a good match in tone between system and setting in the name of drawing more players.
His name is Neutrino. His mass is real, but he is not.
Customer: Waiter! What's this heroine in my coffee!
Waiter: The backstroke, perhaps?
or...
Waiter: Keep yout voice down, or everyone will want to meet her!
or...
Waiter: That's not a heroine, sir. That's heroin. See you tomorrow.
I love the Google Language Tools (Translate: Corporate Swine to English):
"We've finished repositioning, and as the biggest wireless carrier, we can now afford this change better than anyone else. So by pretending to buckle like a belt, we are in fact going to use the full force of the United States Government to sweep most of our minor competitors out of the field. The other big boys can afford it, but we can not only afford it, we can buy up the corpses of the minor players who are going to be creamed trying to comply. We'd thank the FCC publicly, but we don't want to look like a Bond villian in front of our new, larger customer base."
</CYNICISM>
Still, it'll be nice not to be locked to a single carrier by a phone number. If only there'd still be a choice of carriers once this goes into force.
But, when I go back to skills that are being swiftly replace, I do so for one of two reasons: I want a thing that no one else makes, or the modern variant is unacceptable.
Example one: I wanted a desk, so I took up furniture carpentry. Because Ikea doesn't make desks that are worth a damn, and no manufacturer was going to produce the marvelously functional desk I desired. I think the four sided over-desk shelves is the part that's beyond mass appeal. Granted, the reason I take up a skill never turns out well, but as I improve, I remake them. Not as easy as recompiling a minor version upgrade, but it gets me out of doors. This kind of "old world" skill, I take up so that I can add to the realm of what exists, or to discover new techniques, etc.
Example two: I've been very disturbed by the trends I've seen in modern razors. I hate the goo strips, Mach3 heads open new nostrils in my cheeks, and a basic, non-swiveling, non-goo disposable is going to be sharp for about three shaves. So, without any desire to improve on it, I've taught myself (with surprisingly little blood loss) to shave with an open razor. To a great deal I feel vindicated in the decision, since the resulting shaves are vastly superior.
I feel like I could clearly draw a parrallel in either case to my motives for hacking. I learn Unix derivatives because no one's really done it better yet, even though they want to charge me outragous prices for two and a half shaves. I learn a horde of programming languages and command line tools and design skills so that I can make my own.
You're real problem is not explaining things - I mean, we understood a year to be a different length in The Dark Crystal for Henson's sake, and that was just muppets. It's selling the setting. A science fiction reader will buy the whole toroidal gas cloud once it's explained. But without explaining, how do you sell the basic facts of the setting: atmosphere in orbit? Maybe a rocket-truck from way out where you can see the whole smoke ring way in past little people floating in air to a Tree? Solve the selling question and the movie just rolls along. Well, that and financing yet another not-frame-untouched SFX extravaganza.
First and absolutely foremost: an FSM is an adstract concept born of graph theory. A statechart is a diagram of an FSM, which complies to a rigorous specification for what each notation means.
The statechart spec adds a few semantically trivial notations (i.e. they can be easily translated into standard digraph style FSM), which are nonetheless extremely useful for presenting clear, easy to understand diagrams.
Most of those additions have been mentioned already (e.g. nesting) but there are also guard conditions (i.e. transition if X except if y), and indications of entrance, presence, and exit behavior. Very handy for describing behavior.
Sure, it's important to store your results, but it's also important to load your operands, and the Von Neumann cycle doesn't address either operation.
Some implementations add a step between 1 and 2 that says "increment the program counter" and leave jumps up to specific instructions. Others associate program counter changes with every instruction (i.e. jumps go to somewhere specific, every other instruction also implies PC++.)
There's nothing more to Von Neumann machines. They are unrelated to finite state machines or Turing machines, except that every Von Neuman machine can be modelled as a Turing machine. The difference is that a Turing machine is a mathematical abstraction, whereas Von Neuman machines are an architecture for implementing them.
Whoo hoo. And yes, I am a computer scientist. Or maybe a cogigrex.
Cuz, cus, that movie is fucked up. Cannot say it strongly enough. Had cause once to compare it to Urotsukidoji, and the DVDA tentacle rape came out on top. I mean, c'mon. He goes after her with the drill penis! And she gets away, and then she asks him to use it! And he does. Messily! He gets his powers from jamming a ribbed metal pipe into his festering thigh wound, after being hit by a car!
I mean, if I wanted postwar analysis of the dehumanization of our culture in black and white by a former Axis power, can't I just watch Metropolis. Please, pretty please? I'm begging you, I'm groveling, not the 50 hoursepower drill phallus! Have mercy!
Split Second is one hell of a romp. Formative of my childhood. Best part is Hauer's nebbish partner transformed by seeing the thing.
"We need big fucking guns!" (Examining an auto-shotgun.) "Too fucking small! Bigger!"
Fun fun fun.
This product contains copy-protection. The Attorney General has determined that copy-protection may be hazardous to your Fair Use. College students especially should not buy or use this product.