The IBM lab in Toronto used to have a system like this, back before Celestica was spun off; half the lab did software and the other half was manufacturing. I recall one manufacturing guy got the maximum suggestion award for saying let's use just one stabilizer foot instead of two on each PC case.
I submitted an idea that a back-of-the-envelope calculation suggested would result in quite a bit of savings. Downgrade all the "work-at-home" sponsored phone lines from business grade to regular consumer grade. This was in the mid-90s with very slow modems, not exactly taxing to the phone system. Suggestion declined.
Then a couple of years later it was announced that they would do what I suggested. I inquired if the award still applied. It was just like when your warranty expires and your computer breaks. The two-year "statute of limitations" on suggestion awards expired, and the suggestion was implemented shortly after.
Which is a roundabout way to say, in the hardware/manufacturing world they may pay out for productivity suggestions, but don't count on it in the software business. (After all, who hasn't had an idea that would speed up some process 1000x and make some slacker in their office redundant? A slacker who serves on the committee evaluating suggestions.)
How does documentation get 'bugs', with access to the source and the developers it would be straight forward to get each programmer to write up a high-level description of what each function does, gather that into a spec, and voilà, there's your documentation already.
I take it you've never actually seen any source code, or met any programmers?
This function does something that makes no sense unless you already understand 5 layers of other workarounds.
That function does exactly the opposite of what its name suggests, leading to a never-ending cycle of bug reports because no one believes the documentation.
This programmer reviewed and signed off on the documentation for the last 5 releases, which was prepared from their writeup. A different reviewer discovered 100 mistakes in said documentation.
That programmer is a perfectionist who opens a bug for every nit they want to pick regarding grammar and punctuation. (And they're frequently wrong.)
I think the problem is the false assumptions and analogies that get introduced by these lines of thinking. If a network is "this guy talking to that guy", your thinking will be constrained by what you know about human conversation. If there's a problem, someone can talk louder, slower, etc. and the analogy holds. But if the solution involves something that has no equivalent in the day-to-day world, how are you going to conceptualize it?
My pet peeve, that descends from this same idea, is from the teaching of object orientation. A car is a type of vehicle; a truck is a type of vehicle; they both have wheels; maybe the number of wheels is different; maybe each has a different turning radius or procedure for backing up.
Great, now you understand inheritance, polymorphism, member functions, etc. However, in practice, you use object orientation to avoid zillions of "if" statements, special case code, large blocks of almost-but-not-quite duplicated code.
In my experience, someone who learned OO by simple analogies is likely to be locked into thinking "I have to write every program by making a tree of classes like with the cars and trucks". Rather than "there are different ways to structure the code, and a good OO way will get rid of a lot of branching, magic numbers, and redundant code".
I've noticed that the most frequent cause of Safari crashes is a Javascript issue that gets triggered sometimes when leaving a page on Slashdot. Maybe the real target of Chrome is not IE or Firefox, but Slashdot.:-)
I've been thinking about this issue a lot lately, as I've recently hit a new decade. It's all about the context. Put someone with just slightly more experience in with a bunch of newbies, and they'll be a natural leader who can guide them forward. Put someone with tons more experience in with the same bunch of newbies, and it'll be a disaster.
Just imagine if the (smart) CEO of the company was dropped into the middle of an IT or development department. At the first meeting where they debated whether to use this or that methodology, the CEO would probably tell them it doesn't make the slightest bit of difference -- the most important thing for this department is to hit this deadline, get this feature close enough to finished that the salespeople can add it to their checklist, or conform to some obscure government regulation to avoid months of red tape for some other department. Doesn't matter how true it is, that viewpoint wouldn't be welcome.
Think of some area where you have many years of experience -- XML, Java, coding standards, Linux, whatever. Chances are you have dealt with aspects that have been the subject of heated community debates. Chances are also good that you have evolved your position over time, maybe to the point of reaching precisely the opposite conclusion than you originally would have. Or maybe you've even switched back and forth several times. (It's better to get code correct than make it fast; but fast code delivered early can make a good first impression in the market; but sloppy code is hard to refactor; but well-planned code can be refactored successfully.) So what happens if that if you are only a little more experienced than your peers, maybe you can convince them that your counterintuitive suggestion makes sense. But if you are a lot more experienced, it's hard to get across the reasoning for your counterintuitive suggestion, if that involves thinking through several levels like that.
One of Google's pet interview questions is "what is the biggest challenge you've faced". If you've got a couple of years of work experience, you've probably only had one challenging project and the answer is a slam dunk. If you've got many years of experience, it gets more complicated -- do you want the biggest teamwork challenge, the toughest code to write, the most ridiculous deadline...? And some of the most impressive accomplishments don't really fit that answer, because by now it's routine to crank out great code under ridiculous deadlines while dodging company politics. Google might prefer to hear that your last startup crashed and burned, but now you've really learned your lesson. (Lesson #2 of 50 that the old-timer has internalized.)
I remember when my third-line manager tried to clean out his mail. He had made copies of messages in various folders and then deleted messages from the inbox. But the messages in folders were just pointers, not real copies, and he lost all his e-mail.
As a former IBMer, I have to say you've perfectly captured the feelings someone would have working in the DB2 area and forced to use Lotus Notes for mail and groupware-type stuff. When someone asks why I left, Notes always comes up in the conversation.
From the interview, the OED project was partly sponsored by IBM, which would have been the IBM Canada Lab where I worked. In fact, I think my department was involved in some way with the OED work.
I had always thought that SGML evolved into XML too, but from the article it sounds like maybe it's a separate branch descended straight from GML. Since both were IBM-influenced, makes sense that they would look similar.
(GML?)
Long before SGML or XML, IBM had "GML" which was a set of tags that you would find very familiar today. p for paragraph, ul for unordered list, h1 for heading level 1. Closing tags for paragraphs and list items were optional. Only thing was, they used different delimiters, so the markup looked like::h1.First-Level Heading:eh1.
The DTD was actually better than any SGML or XML DTD I've used for publishing since, because it had a lot of good semantic tags for reference and programming content. You can see echoes of it in Docbook (things like the tags to generate syntax diagrams), but Docbook grew so big that everyone only uses a subset of it.
GML even had tags for doing Gantt charts, and I would dearly love to find a publishing system that could do printouts from such tags. I had a system for tracking schedules by manipulating date attributes within the schedule tags, e.g. "this activity is starting late but must still finish on time; this other activity is starting late and the end date will slip by the same amount".
The unstructured aspect was actually quite useful for publishing. You could define a "type" of table with column widths specified in a variety of relative and absolute ways, including "make the column wide enough to hold the text 'abc xyz'". Support for entities and imported content was also useful. Then you could create multiple instances of that table type. In practice, I found that was more intuitive than (say) defining via CSS. You could define a couple of entities one way and pull in a module that used them; then redefine them and pull in the same module again, to produce slightly different versions of the same content. Ditto the conditional text facility, all tag- and text-based, with enough flexibility to be useful.
IBM switched to various SGML and XML DTDs for publishing back in the mid-to-late '90s, but the restrictions and draconian error handling represented a step backwards IMHO. Here it is 10 years later, and we still haven't gotten back to the level of ease of use and flexibility that GML had in the '80s.
the sheer "fit and finish" that goes into the GUI - NEVER will you have a busy or hung application that displays white contents when you drag something else over it, OS X stores the contents of a GUI app in a different way so that even when the app is hung it can be nicely moved around;
What special members-only version of OS X you running? On both Jaguar and Panther, I frequently have apps lock up in ways that prevent me from getting to Force-Quit, minimizing the app's windows, or getting to the dock. Applications that crash like this are things like Firefox, Mail.app, the Finder...
Problem is that OS X has many variations of bad things that happen when devices are removed. I have one USB peripheral -- an input device, not a drive -- whose driver crashes the system if this happens. I have had many apparent hangs of the Finder due to a network share where the computer on the other end was put to sleep or rebooted. On the software end, browsers tend to hang rather than timing out gracefully if they suddenly can't get to the network.
If you work on a corporate Unix system, you might be familiar with the situation where an important NFS drive stops working. Everyone has it in their $PATH, so almost any command they type hangs the shell trying to access the NFS drive. So it appears that "my system is locked up" or "the whole network is down" even though it's an isolated and easily-worked-around problem.
>I also enjoyed Byte and have issues going back to the early 80's.
For some reason, the style and/or tone of Byte always made me feel nauseous. I still remember the band practice in 1983 when someone lent me an issue. No other magazine before or since has had that effect on me. Seriously, I would feel ill reading it, didn't matter which issue.
Somehow the articles always seemed geared to the clueless CIO ("We review the 200 fastest 386 desktops!"). All the articles I read about programming techniques, nifty gear, research projects, etc. and none of them ever helped me a bit as either a hobbyist or a CS major.
Maybe it was the Intel-centric view of the world. The only issue I ever kept (still have it in my office somewhere) was the one with the cover story "Amiga 3000: Ready for Prime Time".:-)
The Palm Desktop for OS X has just about the worst user interface I've seen since about 1999 (when I stopped using Lotus Notes). It looks like the Windows and Mac developers don't ever talk to each other. No way to create a text note for a to-do item on the Mac? Weird Mac-only menu items? Ugly fonts that don't look any better at any size? It's just lameness personified.
I don't care so much about the synch issues, since I did buy Missing Sync, but I gave up synching with the Mac since Palm Desktop was so lousy. What's missing on the Mac side is (a) a good integrated PIM app that does all the functions (particularly to-do list), and (b) file compatibility with the PC version of Palm Desktop, so I could mirror the files and have access to calendar, to-do, etc. on both Mac and PC, regardless of which machine is used to synch.
* A license for removable solid state media manufacturers to preformat the media, such as compact flash memory cards, to the Microsoft FAT file system format, and to preload data onto such preformatted media using the Microsoft FAT file system format.
Why wouldn't a CompactFlash manufacturer have the same rights as someone who sticks a floppy in their computer, formats the floppy, copies some software onto it, then sells the floppy?
Right, any given solution might turn out to be non-optimal on a machine with just slightly different specs (more or less memory; different amount of cache memory; faster or slower hard drive; more or less contention from other programs).
Seems like most useful where the program itself is crucial, e.g. code whose innards are fairly stable, and that takes a long time to run. You can probably also draw some generalizations to say that certain options are recommended for programs "like" Linpack. This is the area that interests me more, to find the similarities between programs that make them amenable to certain options.
Back in the '90s I worked at IBM documenting compilers. Also, I wrote a kind of expert system for the XL Fortran compiler that would ask some yes/no questions and recommend sets of likely options.
Often the advice in the documentation boiled down to "try a a bunch of combinations and see what helps". The technique in this article sounds like a better mousetrap when someone is actually willing to take the time and effort to do that analysis. I don't know if, by knowing it, we could have offered any more practical advice though to J. Average User with an arbitrary program.
I don't care about the push pin on the map, I just want the last line of the driving instructions to say "it's on the right side" or "it's on the left side" based on the direction it's told me to drive.
On a related note, are there free and easy-to-use Gantt charting programs available?
Back in '89 it was really easy to produce and print Gantt charts using XML-like markup on an IBM mainframe. I had editor macros that would do things like change the expected end dates for a group of items, or change both the start and end dates.
Since IBM unplugged that mainframe, I haven't seen anything like that functionality. Everything is graphically based and so not automatable, or kludged up in Excel, or elderly shareware written for Win 3.1 in Visual Basic.
Re:Hilights problems with compulsory licensing
on
Why Only Music?
·
· Score: 1
I'm imagining a steady stream of royalty payments once I make all those "pictures of my cat" available for compulsory licensing.
A rom image is likely to contain device driver calls that set register bits that have no equivalent on other hardware.
If there's no equivalent at all on the other hardware, of course direct translation falls down. But so would emulation. So would porting. Kind of a moot point. I didn't see that the article was saying otherwise. They were up front about shortcomings with, for example, self-modifying code.
My point was that in cases where emulation was possible, then translation would be too. If an emulator could parse the next opcode and issue a sequence of calls like
store value to address
check if this is special memory-mapped register
if so, call appropriate graphics/sound/etc. routine
then a translator could produce #defines or whatever to do the same set of steps, saving the parsing overhead. So if MAME on a PC can emulate the sounds, sprites, etc. of an old arcade game with a Z80 chip, presumably translation would be possible too.
People are frugal, everyone's afraid of their job being sent to India, and everyone's well aware that any company trying to charge for content will be under pressure from investors to show ever-increasing revenues. (So they will try to charge for absolutely every page view they can get away with, or will raise prices the moment business levels off.)
For you who hate Microsoft and hate the abuse of patents, do you know which side to take?
Now I'm back on the side of Eolas. No matter what I feel about Microsoft or software patents, I can't stand Lotus Notes! (I used to work at IBM in the database division, but whenever anyone did anything with "databases" it was always some crappy Notes application.)
I took an SF writing course from Rob Sawyer in Toronto a few years back, and he very clearly spelled out all the hardships and financial considerations to making a living at it. (Submitting work for literary prizes, making deals to get stuff reprinted, translating into other languages for a broader audience.)
It may be that today the potential SF writers simply can't devote all that time to it, especially if it's a second job. I work in the tech writing division of a software company. (Some might say that's already science fiction.) Other potential SF authors (or readers) might spend all their free time contributing to open-source projects or otherwise helping to bring about the future. Certainly a lot of them live in high-cost areas that discourage going out on a limb by becoming a full-time author.
I think it's natural to expect a period of pessimism as new technology gets assimilated, before society starts to explore new future directions in SF.
For example, back in the old days, they had fables and myths with swords in stones, golden arrows, afterlives where you would hunt all the time or re-enact glorious battles. Then came firearms. Now instead of the Iliad and King Arthur, we have "The Good, the Bad, and the Ugly", "Bonnie and Clyde" and "Saving Private Ryan". A little less romantic to be sure.
Slashdot Mirror
The IBM lab in Toronto used to have a system like this, back before Celestica was spun off; half the lab did software and the other half was manufacturing. I recall one manufacturing guy got the maximum suggestion award for saying let's use just one stabilizer foot instead of two on each PC case.
I submitted an idea that a back-of-the-envelope calculation suggested would result in quite a bit of savings. Downgrade all the "work-at-home" sponsored phone lines from business grade to regular consumer grade. This was in the mid-90s with very slow modems, not exactly taxing to the phone system. Suggestion declined.
Then a couple of years later it was announced that they would do what I suggested. I inquired if the award still applied. It was just like when your warranty expires and your computer breaks. The two-year "statute of limitations" on suggestion awards expired, and the suggestion was implemented shortly after.
Which is a roundabout way to say, in the hardware/manufacturing world they may pay out for productivity suggestions, but don't count on it in the software business. (After all, who hasn't had an idea that would speed up some process 1000x and make some slacker in their office redundant? A slacker who serves on the committee evaluating suggestions.)
How does documentation get 'bugs', with access to the source and the developers it would be straight forward to get each programmer to write up a high-level description of what each function does, gather that into a spec, and voilà, there's your documentation already.
I take it you've never actually seen any source code, or met any programmers?
This function does something that makes no sense unless you already understand 5 layers of other workarounds.
That function does exactly the opposite of what its name suggests, leading to a never-ending cycle of bug reports because no one believes the documentation.
This programmer reviewed and signed off on the documentation for the last 5 releases, which was prepared from their writeup. A different reviewer discovered 100 mistakes in said documentation.
That programmer is a perfectionist who opens a bug for every nit they want to pick regarding grammar and punctuation. (And they're frequently wrong.)
I think the problem is the false assumptions and analogies that get introduced by these lines of thinking. If a network is "this guy talking to that guy", your thinking will be constrained by what you know about human conversation. If there's a problem, someone can talk louder, slower, etc. and the analogy holds. But if the solution involves something that has no equivalent in the day-to-day world, how are you going to conceptualize it?
My pet peeve, that descends from this same idea, is from the teaching of object orientation. A car is a type of vehicle; a truck is a type of vehicle; they both have wheels; maybe the number of wheels is different; maybe each has a different turning radius or procedure for backing up.
Great, now you understand inheritance, polymorphism, member functions, etc. However, in practice, you use object orientation to avoid zillions of "if" statements, special case code, large blocks of almost-but-not-quite duplicated code.
In my experience, someone who learned OO by simple analogies is likely to be locked into thinking "I have to write every program by making a tree of classes like with the cars and trucks". Rather than "there are different ways to structure the code, and a good OO way will get rid of a lot of branching, magic numbers, and redundant code".
I've noticed that the most frequent cause of Safari crashes is a Javascript issue that gets triggered sometimes when leaving a page on Slashdot. Maybe the real target of Chrome is not IE or Firefox, but Slashdot. :-)
I've been thinking about this issue a lot lately, as I've recently hit a new decade. It's all about the context. Put someone with just slightly more experience in with a bunch of newbies, and they'll be a natural leader who can guide them forward. Put someone with tons more experience in with the same bunch of newbies, and it'll be a disaster.
Just imagine if the (smart) CEO of the company was dropped into the middle of an IT or development department. At the first meeting where they debated whether to use this or that methodology, the CEO would probably tell them it doesn't make the slightest bit of difference -- the most important thing for this department is to hit this deadline, get this feature close enough to finished that the salespeople can add it to their checklist, or conform to some obscure government regulation to avoid months of red tape for some other department. Doesn't matter how true it is, that viewpoint wouldn't be welcome.
Think of some area where you have many years of experience -- XML, Java, coding standards, Linux, whatever. Chances are you have dealt with aspects that have been the subject of heated community debates. Chances are also good that you have evolved your position over time, maybe to the point of reaching precisely the opposite conclusion than you originally would have. Or maybe you've even switched back and forth several times. (It's better to get code correct than make it fast; but fast code delivered early can make a good first impression in the market; but sloppy code is hard to refactor; but well-planned code can be refactored successfully.) So what happens if that if you are only a little more experienced than your peers, maybe you can convince them that your counterintuitive suggestion makes sense. But if you are a lot more experienced, it's hard to get across the reasoning for your counterintuitive suggestion, if that involves thinking through several levels like that.
One of Google's pet interview questions is "what is the biggest challenge you've faced". If you've got a couple of years of work experience, you've probably only had one challenging project and the answer is a slam dunk. If you've got many years of experience, it gets more complicated -- do you want the biggest teamwork challenge, the toughest code to write, the most ridiculous deadline...? And some of the most impressive accomplishments don't really fit that answer, because by now it's routine to crank out great code under ridiculous deadlines while dodging company politics. Google might prefer to hear that your last startup crashed and burned, but now you've really learned your lesson. (Lesson #2 of 50 that the old-timer has internalized.)
I remember when my third-line manager tried to clean out his mail. He had made copies of messages in various folders and then deleted messages from the inbox. But the messages in folders were just pointers, not real copies, and he lost all his e-mail.
Ah, Lotus Notes, I don't miss it for a second!
As a former IBMer, I have to say you've perfectly captured
the feelings someone would have working in the DB2 area
and forced to use Lotus Notes for mail and groupware-type
stuff. When someone asks why I left, Notes always comes up
in the conversation.
From the interview, the OED project was partly sponsored by IBM, which would have been the IBM Canada Lab where I worked. In fact, I think my department was involved in some way with the OED work.
:h1.First-Level Heading:eh1.
I had always thought that SGML evolved into XML too, but from the article it sounds like maybe it's a separate branch descended straight from GML. Since both were IBM-influenced, makes sense that they would look similar.
(GML?)
Long before SGML or XML, IBM had "GML" which was a set of tags that you would find very familiar today. p for paragraph, ul for unordered list, h1 for heading level 1. Closing tags for paragraphs and list items were optional. Only thing was, they used different delimiters, so the markup looked like:
The DTD was actually better than any SGML or XML DTD I've used for publishing since, because it had a lot of good semantic tags for reference and programming content. You can see echoes of it in Docbook (things like the tags to generate syntax diagrams), but Docbook grew so big that everyone only uses a subset of it.
GML even had tags for doing Gantt charts, and I would dearly love to find a publishing system that could do printouts from such tags. I had a system for tracking schedules by manipulating date attributes within the schedule tags, e.g. "this activity is starting late but must still finish on time; this other activity is starting late and the end date will slip by the same amount".
The unstructured aspect was actually quite useful for publishing. You could define a "type" of table with column widths specified in a variety of relative and absolute ways, including "make the column wide enough to hold the text 'abc xyz'". Support for entities and imported content was also useful. Then you could create multiple instances of that table type. In practice, I found that was more intuitive than (say) defining via CSS. You could define a couple of entities one way and pull in a module that used them; then redefine them and pull in the same module again, to produce slightly different versions of the same content. Ditto the conditional text facility, all tag- and text-based, with enough flexibility to be useful.
IBM switched to various SGML and XML DTDs for publishing back in the mid-to-late '90s, but the restrictions and draconian error handling represented a step backwards IMHO. Here it is 10 years later, and we still haven't gotten back to the level of ease of use and flexibility that GML had in the '80s.
What special members-only version of OS X you running? On both Jaguar and Panther, I frequently have apps lock up in ways that prevent me from getting to Force-Quit, minimizing the app's windows, or getting to the dock. Applications that crash like this are things like Firefox, Mail.app, the Finder...
Problem is that OS X has many variations of bad things that happen when devices are removed. I have one USB peripheral -- an input device, not a drive -- whose driver crashes the system if this happens. I have had many apparent hangs of the Finder due to a network share where the computer on the other end was put to sleep or rebooted. On the software end, browsers tend to hang rather than timing out gracefully if they suddenly can't get to the network.
If you work on a corporate Unix system, you might be familiar with the situation where an important NFS drive stops working. Everyone has it in their $PATH, so almost any command they type hangs the shell trying to access the NFS drive. So it appears that "my system is locked up" or "the whole network is down" even though it's an isolated and easily-worked-around problem.
>I also enjoyed Byte and have issues going back to the early 80's.
:-)
For some reason, the style and/or tone of Byte always made me feel nauseous. I still remember the band practice in 1983 when someone lent me an issue. No other magazine before or since has had that effect on me. Seriously, I would feel ill reading it, didn't matter which issue.
Somehow the articles always seemed geared to the clueless CIO ("We review the 200 fastest 386 desktops!"). All the articles I read about programming techniques, nifty gear, research projects, etc. and none of them ever helped me a bit as either a hobbyist or a CS major.
Maybe it was the Intel-centric view of the world. The only issue I ever kept (still have it in my office somewhere) was the one with the cover story "Amiga 3000: Ready for Prime Time".
The Palm Desktop for OS X has just about the worst user interface I've seen since about 1999 (when I stopped using Lotus Notes). It looks like the Windows and Mac developers don't ever talk to each other. No way to create a text note for a to-do item on the Mac? Weird Mac-only menu items? Ugly fonts that don't look any better at any size? It's just lameness personified.
I don't care so much about the synch issues, since I did buy Missing Sync, but I gave up synching with the Mac since Palm Desktop was so lousy. What's missing on the Mac side is (a) a good integrated PIM app that does all the functions (particularly to-do list), and (b) file compatibility with the PC version of Palm Desktop, so I could mirror the files and have access to calendar, to-do, etc. on both Mac and PC, regardless of which machine is used to synch.
Yeah, I remember how well the "IBM uses it internally" argument worked for OS/2.
* A license for removable solid state media manufacturers to preformat the media, such as compact flash memory cards, to the Microsoft FAT file system format, and to preload data onto such preformatted media using the Microsoft FAT file system format.
Why wouldn't a CompactFlash manufacturer have the same rights as someone who sticks a floppy in their computer, formats the floppy, copies some software onto it, then sells the floppy?
Right, any given solution might turn out to be non-optimal on a machine with just slightly different specs (more or less memory; different amount of cache memory; faster or slower hard drive; more or less contention from other programs).
Seems like most useful where the program itself is crucial, e.g. code whose innards are fairly stable, and that takes a long time to run. You can probably also draw some generalizations to say that certain options are recommended for programs "like" Linpack. This is the area that interests me more, to find the similarities between programs that make them amenable to certain options.
Back in the '90s I worked at IBM documenting compilers. Also, I wrote a kind of expert system for the XL Fortran compiler that would ask some yes/no questions and recommend sets of likely options.
Often the advice in the documentation boiled down to "try a a bunch of combinations and see what helps". The technique in this article sounds like a better mousetrap when someone is actually willing to take the time and effort to do that analysis. I don't know if, by knowing it, we could have offered any more practical advice though to J. Average User with an arbitrary program.
I don't care about the push pin on the map, I just want the last line of the driving instructions to say "it's on the right side" or "it's on the left side" based on the direction it's told me to drive.
On a related note, are there free and easy-to-use Gantt charting programs available?
Back in '89 it was really easy to produce and print Gantt charts using XML-like markup on an IBM mainframe. I had editor macros that would do things like change the expected end dates for a group of items, or change both the start and end dates.
Since IBM unplugged that mainframe, I haven't seen anything like that functionality. Everything is graphically based and so not automatable, or kludged up in Excel, or elderly shareware written for Win 3.1 in Visual Basic.
I'm imagining a steady stream of royalty payments once I make all those "pictures of my cat" available for compulsory licensing.
If there's no equivalent at all on the other hardware, of course direct translation falls down. But so would emulation. So would porting. Kind of a moot point. I didn't see that the article was saying otherwise. They were up front about shortcomings with, for example, self-modifying code.
My point was that in cases where emulation was possible, then translation would be too. If an emulator could parse the next opcode and issue a sequence of calls like
store value to address
check if this is special memory-mapped register
if so, call appropriate graphics/sound/etc. routine
then a translator could produce #defines or whatever to do the same set of steps, saving the parsing overhead. So if MAME on a PC can emulate the sounds, sprites, etc. of an old arcade game with a Z80 chip, presumably translation would be possible too.
Once I understood your logic, MAME suddenly stopped working!
People are frugal, everyone's afraid of their job being sent to India, and everyone's well aware that any company trying to charge for content will be under pressure from investors to show ever-increasing revenues. (So they will try to charge for absolutely every page view they can get away with, or will raise prices the moment business levels off.)
Now I'm back on the side of Eolas. No matter what I feel about Microsoft or software patents, I can't stand Lotus Notes! (I used to work at IBM in the database division, but whenever anyone did anything with "databases" it was always some crappy Notes application.)
The UI of Notes is so bad it got its own section in the Interface Hall of Shame.
What a great idea. Excuse me while I go off and register companies named "IBM Music", "Microsoft Music", and "HP Music".
I took an SF writing course from Rob Sawyer in Toronto a few years back, and he very clearly spelled out all the hardships and financial considerations to making a living at it. (Submitting work for literary prizes, making deals to get stuff reprinted, translating into other languages for a broader audience.)
It may be that today the potential SF writers simply can't devote all that time to it, especially if it's a second job. I work in the tech writing division of a software company. (Some might say that's already science fiction.) Other potential SF authors (or readers) might spend all their free time contributing to open-source projects or otherwise helping to bring about the future. Certainly a lot of them live in high-cost areas that discourage going out on a limb by becoming a full-time author.
I think it's natural to expect a period of pessimism as new technology gets assimilated, before society starts to explore new future directions in SF.
For example, back in the old days, they had fables and myths with swords in stones, golden arrows, afterlives where you would hunt all the time or re-enact glorious battles. Then came firearms. Now instead of the Iliad and King Arthur, we have "The Good, the Bad, and the Ugly", "Bonnie and Clyde" and "Saving Private Ryan". A little less romantic to be sure.