Sega screwed everyone first, then was tagged as a weak company, and everyone knew it. They could have come out with a console 50 times better than anyone else's, and they still would have failed, because nobody believed they would be around next month.
If you knew Mercedes was going broke, would you buy a Mercedes? Of course not, you'd buy a Lexus or a Beamer or something else equally silly and ostentatious.
Everyone knows Microsoft is going to be around, and they've already shown extreme patience in this market. So there is no risk buying their new console.
Which is why the whole Sega analogy is dumb, as the AC points out.
Funny, but ill-advised, and certainly not "insightful." VB is an amazing productivity tool. Your kids will code circles around you while you are busy picking up mod points.
What we really need is an open-source VB equivalent. It's worrying that so many slashdotters don't seem to grasp this.
What kind of porn are you watching, anyway, where they bother with post-production touch-up -- or plot, for that matter?
Classic marketing error
on
OQO Examined
·
· Score: 1
Right, this device has no future whatsoever. It's always a mistake to produce a unit that fits "between" a high-end and a low-end device, especially if it is clobbered by the low-end price and offers quite nebulous advantages over the low-end unit -- AND if it's not very competitive price-wise with the high-end unit. It will be squeezed from both sides. Buh-bye.
There are plenty of examples of this phenomenon. For instance, who will be left standing in the commercial database wars? Oracle has the high end, Microsoft the low end, and where are all the other commercial players? Dead or dying, except for IBM, which can generate enough internal business all by itself to keep DB2 alive.
There are always random gadget nuts who will buy stuff just because it's new and semi-different (like some of the posters here). But no CEO I know would carry around a handicapped piece of shit like this. It will never happen.
Hmmm, I guess I'd like to hear "all the reasons [you] think VB is a scourge on the Earth."
How about itemizing a few, to expose your ignorance? Let me help.
1) Incredible productivity. 2) The entire Windows API is available, plus callbacks, to do anything you want, including subclassing and hooking. 3) Compiles to very fast code. 4) Has very few legitimate bugs in the core controls and system, and those are easily worked around. 5) Provides a simple interface to DLL's, where you are free to stuff code that really has to manipulate memory or do other low level stuff that VB isn't good at.
I do admit it can't handle objects very well (ok, at all). But objects only help in a relatively small proportion of programming projects. The rest of the time they are useless quiche anyway.
I've made tons of money shipping commercial code based on VB. Tons. And I wouldn't even have shipped if I hadn't had the productivity multiple it provides.
So I'll put my pile of money against your visceral disgust any day.
Parent is correct, there are a number of "teach yourself VB" books that take you step by step through the process of building real applications that manipulate real screens and controls. These books are very accessible to beginners.
One such book was "Teach yourself VB 3.0", copyright 1994 MIS:Press Inc., ISBN 1-55828-342-0. I'm sure there's a "Teach yourself VB 6.0" (or VB 5.0, same thing) version of this book by now. What I wouldn't suggest is "Teach yourself VB.Net", she'll never get past the introduction.
If I had mod points, I'd mod you down for being so proud of it. An effort at proper grammar and spelling isn't just fussy old-think, it's an attempt to be considerate to your readers.
Amen, brother. It happened to me in 1989. They chopped SIX MONTHS off the software schedule, forced us to ship product. The fact that it took TWELVE MONTHS to finally clean up the mess, and that cleaning up the mess tipped the company into Chapter 11 receivership, didn't prevent the CEO and his chief assistant idiot, the VP Engineering, from moving on to the next victim.
It's funny how history repeats itself. I remember as a young lad in 1977 being part of a study that evaluated various software engineering design methodologies for DoD. All the aerospace companies were claiming great things for PSL/PSA, RSL/RSA, and the other methodologies of the day. Hard figures, too, like you're quoting here. So you'll have to pardon my skepticism, because I've seen similar arguments (and hard figures) like this many times before, and they've all evaporated like the morning mist.
And, call me a cynic, but I can't help being suspicious of anyone who trots out a new software development tool targeted specifically at Ada. It smells too much like an attempt to milk the DoD money machine, which is easy enough to do, rather than sell the idea on its own merit.
Thanks for this thoughtful response, wow! You've given me (and everyone who is reading this) a lot to think about.
One question on the tenure issue: Since you are without tenure in your district, do you feel as though you could be threatened with termination as a result of teaching something having religious or political impact, such as evolution or Communism?
Dave, you sound like a thoughtful and motivated person. I wish all my K-12 teachers had been what I imagine you to be. Unfortunately I found most of them to be burned-out, tired, and uninterested. I can only think of a few teachers who were otherwise.
Your point about parental involvement is interesting. I claim that a causal relationship cannot be established. Are parents involved because they and their kids are motivated and smart, or are the kids motivated and smart because their parents are involved? You can't say; neither can I.
Perhaps, having established yourself in this forum as someone who cares deeply about the subject, you could comment on a few of the other postings here. For example:
1) Would you advocate funneling monies away from sports/music/etc. and back into basic education (English, history, science, math)?
2) How do you feel about the tenure system? Is it good or bad to have a job for life? How do you feel about teacher evaluations? On what criteria should they be performed?
3) What do you think about standardized testing? Do you think it causes people to "teach to the test," rather than learning real material, or do you think that it is a useful tool to evaluate student progress?
4) If you answered (3) in the negative, i.e. you don't approve of standardized testing in K-12, how do you feel about college admissions departments' still-heavy reliance on the SAT?
5) What do you think the purpose of a secondary-school education should be? In Japan, it appears to be to maximize the chances of a college admission. Should it be that way here? In some wealthy suburbs near Boston, for example, it has been the practice for years to give sample SAT's as homework for the entire Junior and Senior years! Not unsurprisingly, those high schools achieve disproportionately high SAT scores. What do you think of this practice?
Thanks in advance for your comments, if you choose to comment.
On my desktop? Never. On my laptop? A lot, everything is ctrl-meta-mumbled due to lack of space. But this product doesn't help me, because the whole point of the laptop is not to have to carry around a keyboard (or anything else, for that matter, with the possible exception of a mouse).
But if somebody shipped a LAPTOP with an illuminated keyboard -- now you're talking. As long as battery life doesn't go to hell, that is. I know, the light could be turned on with a keystroke... shit, never mind.
Actually, what you need more than a reference implementation is a set of assertions to test against, i.e. "state" -- the value of various items or datastructures at a given point in time. The problem, of course, is exactly what DeadSea is complaining about. Where's the reference data going to come from? We should all be so lucky to have such data.
I actually think that the problem goes beyond data.
I proposed a thesis at MIT that leveraged a parser generator to build a state machine representing the proper paths of program execution. Basic idea is that each key section of your program emits a token, the tokens are parsed according to a pre-defined grammar, and the parser generator's built-in syntax checking finds at execution time any paths that weren't anticipated.
In other words, if you can write a grammar that describes all execution paths your program ought to take, then a parse error during testing becomes something that's really quite interesting to drill down on. The token stack tells you what happened, the parser knows what state you're in, what production it's reducing, and so forth, so it's easy to track down not only the call stack, which typically has limited context to tell you what's REALLY going on, but also the overall context of where you are and what the hell you're doing.
Since LR parsers are really, really fast, the state tables they generate are small and tight, and tokens are generated at a relatively low frequency, the whole scheme imposes essentially zero overhead on program execution.
Although the faculty member to whom I proposed this was wholly uninterested (Barbara Liskov: "The problem is not control, it is data" -- thanks for the deep insight, Barb), some guy in Canada got his PhD a couple years later with a similar idea. Don't know whether the concept ever found its way into a commercial product, but I would have killed for it a couple of different times in my career, especially for things like driver-level interrupt routines.
I pick on Rose people because they seem to all say the same stuff
I don't have any great love for Rational Rose, either, so rail on, brother.
I honestly could not see you winning any bids against todays development shops.
Hmm, I guess I'll stand on my record:
1) System designed in 1989, tens of thousands of units sold, still being marketed successfully, as we speak, against "today's development shops." 2) System designed in 1993, tens of thousands of units sold, still being marketed successfully, as we speak, against "today's development shops." 3) System designed in 1996, company was bought out, made $nice in the dot bomb era, unlike many of "today's development shops." 4) System designed in 1999, still producing very significant royalty revenues, apparently experiencing no threat from "today's development shops." 5) System designed in 2001, shipped $millions worth, currently running in multiple Fortune 500 companies, still being marketed today, still considered premier product in its field, experiencing no threat from "today's development shops." 6) System designed in 2003, released a few months ago, already sold to one Fortune 500 company, where it displaced a $3M product produced by "today's development shops."
It really is possible to plan ahead, write successful systems, design them appropriately, and walk away with the business and the rewards.
It's also possible, I suppose, to puke out some crappy code to meet some fool's idea of a specification. I wouldn't know.
This series of comments by AIK is profound. Please get off your apple-pie-and-motherhood methodology soapboxes and pay attention.
Customers do NOT know what they want. Anyone who thinks that they do, hasn't spent enough time architecting software.
What AIK is saying is that you have to dig deeper than the customer requirements. You have to understand the space. You have to look at competitive products. You have to anticipate unstated needs. You should ask, "When I'm all done, and everything is working perfectly, what changes will the customer want IMMEDIATELY?"
I can't stand people who listen for five minutes and start to write "use cases" right away. That works for some dumbass web site, maybe, but certainly not for any involved product design.
Architects need to plot an intercept strategy several YEARS in the future. That's how you build successful software. When the customer puts his Phase N requirements out for bid, and all your competitors run for the hills, your design has anticipated his needs. You've built metatables instead of tables. You've used OLAP where you could have sleazed by with an RDBMS. And so on.
Speaking of standing around watching, have they figured out how to build little blow-up State Police cars with working bubblegum machines, so as to fool the motorists into thinking there's a real cop nearby?
Sure would save the overtime they're currently paying the real cops, several of whom seem to be standing around watching at any given time.
Well, I thought it was pretty damn funny at the time, especially since I had just finished a thread where everyone was "IANAL, but" all over the place. If I hadn't used up my mod points, I'd have awarded one.
Huge numbers of people believe rather unusual things. These beliefs cause them to take actions that can and will affect you. It's important to understand and discuss those actions, and I salute the editors for posting this story.
An expedition to Mt. Ararat seems harmless, in its own way. But it's symptomatic of mankind's need to depend on "faith" for guidance. When "faith" crosses the line to creed-driven violence, one begins to see how dangerous it can be.
Is there no room for rational discussion of these topics? I say there is. Slashdot is a perfect place to have the discussion.
Very dark, very unhappy thoughts. Sounds like you would be much happier working somewhere else? Best wishes to you, my friend. I hope things improve for you.
Putting PNGs all over your customer sites, are you? Brilliant, your customers will love it when their images turn into the blackened shit that IE renders.
IE's market share is what, 95%? So 95% of your visitors will see crap? Sounds reasonable to me -- if I were in a straightjacket in Bellevue, that is.
No, actually, the company's dollar is the same as your dollar. The fact that you don't think that it is means that your company has done a poor job educating you about your responsibilities as an employee and team player. It is possible to save millions for your company, millions that go directly to its bottom line, if you behave responsibly, purchase carefully, and, in general, treat the company's money as though it were your own -- and everyone around you does the same.
You will understand this someday if you start your own business. In the meantime, you are making sourcing consultants rich (who will walk through the door and point out abuses, such as $3 light bulbs, $700 Palm Pilots, and other purchasing stupidities), and you are one of the many termites eating away at the foundation of your enterprise.
Now, you may be someone who disagrees fundamentally with the notion that a company should be allowed to make a profit. In that case, you're behaving perfectly rationally. Spend away! Drive the thing into bankruptcy! Viva la Revolucion! Etcetera!!
Slashdot Mirror
Parent highlights the real point here.
Sega screwed everyone first, then was tagged as a weak company, and everyone knew it. They could have come out with a console 50 times better than anyone else's, and they still would have failed, because nobody believed they would be around next month.
If you knew Mercedes was going broke, would you buy a Mercedes? Of course not, you'd buy a Lexus or a Beamer or something else equally silly and ostentatious.
Everyone knows Microsoft is going to be around, and they've already shown extreme patience in this market. So there is no risk buying their new console.
Which is why the whole Sega analogy is dumb, as the AC points out.
Hmmm, seems to me your troll score is 3 for 3. Good thing you posted anonymously.
1) Is your comment related at all to the text, or are you just ranting in general?
2) He's not exaggerating, and you're off topic, fueling yet another rant.
3) No, actually, the best websites are where the tools of the Web are used in a way consistent with their original intent.
Funny, but ill-advised, and certainly not "insightful." VB is an amazing productivity tool. Your kids will code circles around you while you are busy picking up mod points.
What we really need is an open-source VB equivalent. It's worrying that so many slashdotters don't seem to grasp this.
What kind of porn are you watching, anyway, where they bother with post-production touch-up -- or plot, for that matter?
Right, this device has no future whatsoever. It's always a mistake to produce a unit that fits "between" a high-end and a low-end device, especially if it is clobbered by the low-end price and offers quite nebulous advantages over the low-end unit -- AND if it's not very competitive price-wise with the high-end unit. It will be squeezed from both sides. Buh-bye.
There are plenty of examples of this phenomenon. For instance, who will be left standing in the commercial database wars? Oracle has the high end, Microsoft the low end, and where are all the other commercial players? Dead or dying, except for IBM, which can generate enough internal business all by itself to keep DB2 alive.
There are always random gadget nuts who will buy stuff just because it's new and semi-different (like some of the posters here). But no CEO I know would carry around a handicapped piece of shit like this. It will never happen.
Hmmm, I guess I'd like to hear "all the reasons [you] think VB is a scourge on the Earth."
How about itemizing a few, to expose your ignorance? Let me help.
1) Incredible productivity.
2) The entire Windows API is available, plus callbacks, to do anything you want, including subclassing and hooking.
3) Compiles to very fast code.
4) Has very few legitimate bugs in the core controls and system, and those are easily worked around.
5) Provides a simple interface to DLL's, where you are free to stuff code that really has to manipulate memory or do other low level stuff that VB isn't good at.
I do admit it can't handle objects very well (ok, at all). But objects only help in a relatively small proportion of programming projects. The rest of the time they are useless quiche anyway.
I've made tons of money shipping commercial code based on VB. Tons. And I wouldn't even have shipped if I hadn't had the productivity multiple it provides.
So I'll put my pile of money against your visceral disgust any day.
Parent is correct, there are a number of "teach yourself VB" books that take you step by step through the process of building real applications that manipulate real screens and controls. These books are very accessible to beginners.
One such book was "Teach yourself VB 3.0", copyright 1994 MIS:Press Inc., ISBN 1-55828-342-0. I'm sure there's a "Teach yourself VB 6.0" (or VB 5.0, same thing) version of this book by now. What I wouldn't suggest is "Teach yourself VB.Net", she'll never get past the introduction.
If I had mod points, I'd mod you down for being so proud of it. An effort at proper grammar and spelling isn't just fussy old-think, it's an attempt to be considerate to your readers.
Amen, brother. It happened to me in 1989. They chopped SIX MONTHS off the software schedule, forced us to ship product. The fact that it took TWELVE MONTHS to finally clean up the mess, and that cleaning up the mess tipped the company into Chapter 11 receivership, didn't prevent the CEO and his chief assistant idiot, the VP Engineering, from moving on to the next victim.
...All Computers Inc. patents "electron."
These things have to be squashed. We must all work together. This is ridiculous.
It's funny how history repeats itself. I remember as a young lad in 1977 being part of a study that evaluated various software engineering design methodologies for DoD. All the aerospace companies were claiming great things for PSL/PSA, RSL/RSA, and the other methodologies of the day. Hard figures, too, like you're quoting here. So you'll have to pardon my skepticism, because I've seen similar arguments (and hard figures) like this many times before, and they've all evaporated like the morning mist.
And, call me a cynic, but I can't help being suspicious of anyone who trots out a new software development tool targeted specifically at Ada. It smells too much like an attempt to milk the DoD money machine, which is easy enough to do, rather than sell the idea on its own merit.
RTFA. His machine crapped out for other reasons, he had to re-install from scratch.
Thanks for this thoughtful response, wow! You've given me (and everyone who is reading this) a lot to think about.
One question on the tenure issue: Since you are without tenure in your district, do you feel as though you could be threatened with termination as a result of teaching something having religious or political impact, such as evolution or Communism?
Dave, you sound like a thoughtful and motivated person. I wish all my K-12 teachers had been what I imagine you to be. Unfortunately I found most of them to be burned-out, tired, and uninterested. I can only think of a few teachers who were otherwise.
Your point about parental involvement is interesting. I claim that a causal relationship cannot be established. Are parents involved because they and their kids are motivated and smart, or are the kids motivated and smart because their parents are involved? You can't say; neither can I.
Perhaps, having established yourself in this forum as someone who cares deeply about the subject, you could comment on a few of the other postings here. For example:
1) Would you advocate funneling monies away from sports/music/etc. and back into basic education (English, history, science, math)?
2) How do you feel about the tenure system? Is it good or bad to have a job for life? How do you feel about teacher evaluations? On what criteria should they be performed?
3) What do you think about standardized testing? Do you think it causes people to "teach to the test," rather than learning real material, or do you think that it is a useful tool to evaluate student progress?
4) If you answered (3) in the negative, i.e. you don't approve of standardized testing in K-12, how do you feel about college admissions departments' still-heavy reliance on the SAT?
5) What do you think the purpose of a secondary-school education should be? In Japan, it appears to be to maximize the chances of a college admission. Should it be that way here? In some wealthy suburbs near Boston, for example, it has been the practice for years to give sample SAT's as homework for the entire Junior and Senior years! Not unsurprisingly, those high schools achieve disproportionately high SAT scores. What do you think of this practice?
Thanks in advance for your comments, if you choose to comment.
On my desktop? Never. On my laptop? A lot, everything is ctrl-meta-mumbled due to lack of space. But this product doesn't help me, because the whole point of the laptop is not to have to carry around a keyboard (or anything else, for that matter, with the possible exception of a mouse).
But if somebody shipped a LAPTOP with an illuminated keyboard -- now you're talking. As long as battery life doesn't go to hell, that is. I know, the light could be turned on with a keystroke... shit, never mind.
Actually, what you need more than a reference implementation is a set of assertions to test against, i.e. "state" -- the value of various items or datastructures at a given point in time. The problem, of course, is exactly what DeadSea is complaining about. Where's the reference data going to come from? We should all be so lucky to have such data.
I actually think that the problem goes beyond data.
I proposed a thesis at MIT that leveraged a parser generator to build a state machine representing the proper paths of program execution. Basic idea is that each key section of your program emits a token, the tokens are parsed according to a pre-defined grammar, and the parser generator's built-in syntax checking finds at execution time any paths that weren't anticipated.
In other words, if you can write a grammar that describes all execution paths your program ought to take, then a parse error during testing becomes something that's really quite interesting to drill down on. The token stack tells you what happened, the parser knows what state you're in, what production it's reducing, and so forth, so it's easy to track down not only the call stack, which typically has limited context to tell you what's REALLY going on, but also the overall context of where you are and what the hell you're doing.
Since LR parsers are really, really fast, the state tables they generate are small and tight, and tokens are generated at a relatively low frequency, the whole scheme imposes essentially zero overhead on program execution.
Although the faculty member to whom I proposed this was wholly uninterested (Barbara Liskov: "The problem is not control, it is data" -- thanks for the deep insight, Barb), some guy in Canada got his PhD a couple years later with a similar idea. Don't know whether the concept ever found its way into a commercial product, but I would have killed for it a couple of different times in my career, especially for things like driver-level interrupt routines.
I pick on Rose people because they seem to all say the same stuff
I don't have any great love for Rational Rose, either, so rail on, brother.
I honestly could not see you winning any bids against todays development shops.
Hmm, I guess I'll stand on my record:
1) System designed in 1989, tens of thousands of units sold, still being marketed successfully, as we speak, against "today's development shops."
2) System designed in 1993, tens of thousands of units sold, still being marketed successfully, as we speak, against "today's development shops."
3) System designed in 1996, company was bought out, made $nice in the dot bomb era, unlike many of "today's development shops."
4) System designed in 1999, still producing very significant royalty revenues, apparently experiencing no threat from "today's development shops."
5) System designed in 2001, shipped $millions worth, currently running in multiple Fortune 500 companies, still being marketed today, still considered premier product in its field, experiencing no threat from "today's development shops."
6) System designed in 2003, released a few months ago, already sold to one Fortune 500 company, where it displaced a $3M product produced by "today's development shops."
It really is possible to plan ahead, write successful systems, design them appropriately, and walk away with the business and the rewards.
It's also possible, I suppose, to puke out some crappy code to meet some fool's idea of a specification. I wouldn't know.
This series of comments by AIK is profound. Please get off your apple-pie-and-motherhood methodology soapboxes and pay attention.
Customers do NOT know what they want. Anyone who thinks that they do, hasn't spent enough time architecting software.
What AIK is saying is that you have to dig deeper than the customer requirements. You have to understand the space. You have to look at competitive products. You have to anticipate unstated needs. You should ask, "When I'm all done, and everything is working perfectly, what changes will the customer want IMMEDIATELY?"
I can't stand people who listen for five minutes and start to write "use cases" right away. That works for some dumbass web site, maybe, but certainly not for any involved product design.
Architects need to plot an intercept strategy several YEARS in the future. That's how you build successful software. When the customer puts his Phase N requirements out for bid, and all your competitors run for the hills, your design has anticipated his needs. You've built metatables instead of tables. You've used OLAP where you could have sleazed by with an RDBMS. And so on.
Great thread.
Speaking of standing around watching, have they figured out how to build little blow-up State Police cars with working bubblegum machines, so as to fool the motorists into thinking there's a real cop nearby?
Sure would save the overtime they're currently paying the real cops, several of whom seem to be standing around watching at any given time.
Well, I thought it was pretty damn funny at the time, especially since I had just finished a thread where everyone was "IANAL, but" all over the place. If I hadn't used up my mod points, I'd have awarded one.
Too much coffee, dude. Relax.
Brilliant! Still ROTFLing...
Huge numbers of people believe rather unusual things. These beliefs cause them to take actions that can and will affect you. It's important to understand and discuss those actions, and I salute the editors for posting this story.
An expedition to Mt. Ararat seems harmless, in its own way. But it's symptomatic of mankind's need to depend on "faith" for guidance. When "faith" crosses the line to creed-driven violence, one begins to see how dangerous it can be.
Is there no room for rational discussion of these topics? I say there is. Slashdot is a perfect place to have the discussion.
Very dark, very unhappy thoughts. Sounds like you would be much happier working somewhere else? Best wishes to you, my friend. I hope things improve for you.
Sorry for the typo.
Putting PNGs all over your customer sites, are you? Brilliant, your customers will love it when their images turn into the blackened shit that IE renders.
IE's market share is what, 95%? So 95% of your visitors will see crap? Sounds reasonable to me -- if I were in a straightjacket in Bellevue, that is.
No, actually, the company's dollar is the same as your dollar. The fact that you don't think that it is means that your company has done a poor job educating you about your responsibilities as an employee and team player. It is possible to save millions for your company, millions that go directly to its bottom line, if you behave responsibly, purchase carefully, and, in general, treat the company's money as though it were your own -- and everyone around you does the same.
You will understand this someday if you start your own business. In the meantime, you are making sourcing consultants rich (who will walk through the door and point out abuses, such as $3 light bulbs, $700 Palm Pilots, and other purchasing stupidities), and you are one of the many termites eating away at the foundation of your enterprise.
Now, you may be someone who disagrees fundamentally with the notion that a company should be allowed to make a profit. In that case, you're behaving perfectly rationally. Spend away! Drive the thing into bankruptcy! Viva la Revolucion! Etcetera!!