There's no such claim by the "UML crowd". All statecharts are is a better notation for documenting an FSM than a traditional state diagram.
A statechart allows you to naturally decompose the FSM into simpler parts, which scales better (in terms of diagram size) for large FSMs. There is also some other nice "diagrammatic sugar" such as symbols for the default entry point into a sub-system and so on.
Here's
a book that presents a good case for using statecharts in one particular problem domain. Like any tool, using them for everything would be a mistake. But I think a real advocate of UML wouldn't say you need to make class diagrams of everything, either.
... rat's ass about 64-bit support for any x86 architecture? If you have a real need to address that much memory, you'd be a fool to cheap out and buy inferior hardware like Intel or AMD.
Check out the picture of that couple ...
on
Last-Mile Fiber Optic
·
· Score: 2, Funny
in the home page for Issaquah Highland.
"We met at a Starbucks. She was in one that was across the street from the one I was in"
"We both feel so lucky to be living in a time of such wonderful catalogs."
a human estimate ("I estimate we command 20% of the world wide installed base of databases.") is way off. A lot of Windows applications run on top of Access or SQLServer, which probably puts the real figure at something more like 2%.
Re:Communism
on
RMS Turns 50
·
· Score: 0, Offtopic
You should try Ruby; it's much nicer than either Perl or Python.
That is, if you live in the intersection of the set of people who want a cross between Smalltalk and Perl, and the set of people who enjoy using really immature libraries.
For the rest of us who live in the larger set consisting of the intersection of people who want to get work done and the set of people who want to write code that other people have a prayer of maintaining, Python fits the bill.
how exactly is "mixing" defined? If I put olive oil and tap water in my blender, and crank it on high, it is pretty well mixed, at least temporarily. Is it critical that the "mixture" stay "mixed" over time?
While it is true that computer chess programs will continue to progress, it is often forgotten that human players can progress, too. They don't have very much experience, as yet, of playing a program instead of playing a machine.
For example, the Kasparov - Deep Blue match was extremely short by normal standards. Until Karpov, a world championship match was typically 24 games. Kasparov had very little chance to learn from the first few games and modify his play accordingly. (Also, in such a short match, luck predominates, which favored Deep Blue.)
Please don't underestimate the humans in this equation. World championship level players have improved a lot over the years and will continue to improve.
Ummm ... guess you don't know what a statechart is, do you, Ms. AC?
Thanks for the flame. It made me laugh ... really.
Here's a book that presents a good case for using statecharts in one particular problem domain. Like any tool, using them for everything would be a mistake. But I think a real advocate of UML wouldn't say you need to make class diagrams of everything, either.
... rat's ass about 64-bit support for any x86 architecture? If you have a real need to address that much memory, you'd be a fool to cheap out and buy inferior hardware like Intel or AMD.
"We met at a Starbucks. She was in one that was across the street from the one I was in"
"We both feel so lucky to be living in a time of such wonderful catalogs."
an engineer or a code monkey. I'm a journeyman ... in the best sense of the word.
Is he talking about Mad Penguin's Web site?
Thanks! That's a lot clearer than the Debian page.
and the penultimate item ... Slashdot itself.
a human estimate ("I estimate we command 20% of the world wide installed base of databases.") is way off. A lot of Windows applications run on top of Access or SQLServer, which probably puts the real figure at something more like 2%.
Did Nancy type this for you?
has an excellent intern program.
Thanks a lot, Frater 219, for ensuring that I will continue to bother wasting my time sorting through all the trolls, teens, and alpha-geek-wannabes.
You should try Ruby; it's much nicer than either Perl or Python.
That is, if you live in the intersection of the set of people who want a cross between Smalltalk and Perl, and the set of people who enjoy using really immature libraries.
For the rest of us who live in the larger set consisting of the intersection of people who want to get work done and the set of people who want to write code that other people have a prayer of maintaining, Python fits the bill.
Oh ... desktop ... never mind.
all 8 million credit cards were held by 6 families in an Alabama trailer park.
The University of Wyoming ... where the men are men, and the sheep are scared.
my pet peeve is people who pompously pontificate about meaningless crap like Moore's Law.
how exactly is "mixing" defined? If I put olive oil and tap water in my blender, and crank it on high, it is pretty well mixed, at least temporarily. Is it critical that the "mixture" stay "mixed" over time?
Damn it, I meant playing a program instead of a playing a human. What a maroon!
For example, the Kasparov - Deep Blue match was extremely short by normal standards. Until Karpov, a world championship match was typically 24 games. Kasparov had very little chance to learn from the first few games and modify his play accordingly. (Also, in such a short match, luck predominates, which favored Deep Blue.)
Please don't underestimate the humans in this equation. World championship level players have improved a lot over the years and will continue to improve.
Please don't believe everything the Slashdot editors write. Templates are not being added, and generics are not being built on top of templates.