Voice is the most profitable product that telcos sell. It's also the highest volume, but the one with the most competition.
Don't assume because people talk about "new services" that's their core busines....
Unless of course it's actually good content. Then of the 17000 7000 will each tell 5 friends, who next time they pass a "blue-vert" will accept it - thus next time 42,000 will accept, the third time 103,765 will accept, and so on until world domination is achieved.
How can we use spam to drive progress in AI research?
I say let's require every email sender must pass a turing test before sending an email - thus we require spammers to develop software that is indistinguisable from humans in order to send spam. So spam only comes back when they have - and we simply then ask the new AI's for a solution.
Evolution in action.;-)
Does anyone actually think of the complexities of _porting_ a game from a ZX spectrum to a mobile phone?
First you'd need to update the graphics - consumers just wouldn't be satisfied with the graphics from ZX Spectrum era.
You'd then need to update the interaction as many of these phones don't have the same keyboard layouts as a ZX Spectrum. %-)
Finally you'd need to update the code from the assembler it's likely to be in into something maintainable - I think you'd end up going for C/C++ for these modern devices.
All in all what I think you'd end up doing is re-implementing a "clone" of the game.
I've seen this problem happen. Typically when people start to assume that "old" code requires increasingly less maintenance. My experience is that code tends to follow a bathtub curve for maintenance effort. Initally it has a high level of maintenance required, then this drops off to a low level, then at some point in the future it requires a high level of maintenance again. (look at all those late peaks around y2k for an example!)
This leads me to think that any released code should come with a "best before" date stamped on it. So if you have 100 people write code for a year, and it's all "best before" 5 years from that time - you _know_ that you are going to have more maintenance effort 5 years after release - even though in the 4th year there may be less. Of course in the real world individual components have different best before dates from each other - but at least it highlight's it's never over.....
Slashdot Mirror
Voice is the most profitable product that telcos sell. It's also the highest volume, but the one with the most competition. Don't assume because people talk about "new services" that's their core busines....
Unless of course it's actually good content. Then of the 17000 7000 will each tell 5 friends, who next time they pass a "blue-vert" will accept it - thus next time 42,000 will accept, the third time 103,765 will accept, and so on until world domination is achieved.
How can we use spam to drive progress in AI research? I say let's require every email sender must pass a turing test before sending an email - thus we require spammers to develop software that is indistinguisable from humans in order to send spam. So spam only comes back when they have - and we simply then ask the new AI's for a solution. Evolution in action. ;-)
Does anyone actually think of the complexities of _porting_ a game from a ZX spectrum to a mobile phone? First you'd need to update the graphics - consumers just wouldn't be satisfied with the graphics from ZX Spectrum era. You'd then need to update the interaction as many of these phones don't have the same keyboard layouts as a ZX Spectrum. %-) Finally you'd need to update the code from the assembler it's likely to be in into something maintainable - I think you'd end up going for C/C++ for these modern devices. All in all what I think you'd end up doing is re-implementing a "clone" of the game.
I've seen this problem happen. Typically when people start to assume that "old" code requires increasingly less maintenance. My experience is that code tends to follow a bathtub curve for maintenance effort. Initally it has a high level of maintenance required, then this drops off to a low level, then at some point in the future it requires a high level of maintenance again. (look at all those late peaks around y2k for an example!) This leads me to think that any released code should come with a "best before" date stamped on it. So if you have 100 people write code for a year, and it's all "best before" 5 years from that time - you _know_ that you are going to have more maintenance effort 5 years after release - even though in the 4th year there may be less. Of course in the real world individual components have different best before dates from each other - but at least it highlight's it's never over.....
It's an open architecture - you can plug in new converter types and the system will pick them up. What's stopping you? it's only code.....