If the quotes in some of the replies in this thread are accurate, it seems that the guy really does want XML support in the kernel. If so, he's hopeless.
Yeah, he's pretty clueless about Linux, doesn't understand the difference between the kernel and all the higher layers, doesn't understand the non-organization, etc. He also appears to have no idea how much XML support is already available on Linux.
However, he's right on one important point. The business world is going overwhelmingly to XML as a basis for interoperability. Those of us who care about connecting to other business systems need to plan to, uhm, exploit this.
Anything that helps Linux talk to the rest of the world helps. SOAP is simply a pretty flexible XML based remote procedure call standard (descended from XMLRPC). Even though M$ started it, all the implementations I'm aware of are OS independent ones (Perl, Java, and soon Python) from non-M$ sources.
I assume that intentionally modifying their product to block sites for reasons other than those specified by the users would constitute fraud towards those users. No?
It sounds like you're an MFC programmer who's never used VC++? If you have used it how can you possibly say that an application full of dialogs with one line by 40ish character edit controls designed to edit 100+ character strings doesn't need resizeable dialogs?
(For the fortunate souls who haven't used VC++, I'm referring to the dialogs that contain such things as the list of libraries to link.)
What really gets me is that I've talked to the MFC designers about this in the past. Their consistent response is:
Beginning programmers have a hard time understanding constraint based layout.
It's hard to write GUI editors that support constraint based layout.
Of course this is based on the implication that it's perfectly OK to cripple the tools available to the competent, experienced customer if it makes it easier to con more VB programmers into thinking that they too can be instant C++ programmers! After all there are more suckers and wannabes than there are real C++ programmers so the customer base is larger.
(2) Monolithic design, which is NOT a feature. MS Word has features targeted at lawyers (and useless for everybody else), at accountants, at writers, etc., etc. You don't need most of them, but get all of them anyway. Pluggable modules would have been a much cleaner solution (you are a lawyer? plug in the "Lawyer" module...)
Actually this is one of the things that they were trying to do with COM/OLE/etc. Maybe they'll get there yet but I rather doubt it. It looks like the usual couple of big company problems: (1) too much legacy code to rewrite, and (2) a lot of internal groups with different goals and not all that much desire to work together.
The potential is still there but some of the Linux component platforms may have a better chance simply because the component support will exist before the applications are to bulky to change. Of course there's the eternal question of which component platform is today's favorite...
Good to hear from you. One of the roles I've played as coder geek in several organizations is highly unofficial liason to the writers. Kept getting managers who either didn't want to bother with it or who actually believed that "it's just writing -- they can whip something up at the last minute"... Couldn't always get the writers into planning soon enough, but at least they knew what was coming down.
On the payoff side, several of the best unofficial UI reviewers I've had have been writers. IMHO, they're much more likely to have a feel for how a customer thinks than us coders.
This might work pretty well if the cheat sheet diagram around the input area was built into the PDA. You could even change it for shifts if you use a full screen as in CE machines instead of a silkscreen input area as in Palms.
It would take a bit more vertical space and less horizontal space than Graffiti. This might not be a good tradeoff, since vertical space is more of a premium in the existing PDA footprints.
After 1 1/2 years my graffiti is still mediocre. I suspect that I'd be much faster and with this, but it would take longer to learn and it's very easy to make mistakes quickly.
Slashdot Mirror
If the quotes in some of the replies in this thread are accurate, it seems that the guy really does want XML support in the kernel. If so, he's hopeless.
Yeah, he's pretty clueless about Linux, doesn't understand the difference between the kernel and all the higher layers, doesn't understand the non-organization, etc. He also appears to have no idea how much XML support is already available on Linux.
However, he's right on one important point. The business world is going overwhelmingly to XML as a basis for interoperability. Those of us who care about connecting to other business systems need to plan to, uhm, exploit this.
Anything that helps Linux talk to the rest of the world helps. SOAP is simply a pretty flexible XML based remote procedure call standard (descended from XMLRPC). Even though M$ started it, all the implementations I'm aware of are OS independent ones (Perl, Java, and soon Python) from non-M$ sources.
I assume that intentionally modifying their product to block sites for reasons other than those specified by the users would constitute fraud towards those users. No?
Trust me, you don't want him to... been there...
It's on the Altrasoft website. :-) of languages.
A pretty complete Smalltalk-like browser complete with graphical tree display. Supports a small slew
I think it's XEmacs only.
(For the fortunate souls who haven't used VC++, I'm referring to the dialogs that contain such things as the list of libraries to link.)
What really gets me is that I've talked to the MFC designers about this in the past. Their consistent response is:
Of course this is based on the implication that it's perfectly OK to cripple the tools available to the competent, experienced customer if it makes it easier to con more VB programmers into thinking that they too can be instant C++ programmers! After all there are more suckers and wannabes than there are real C++ programmers so the customer base is larger.
(2) Monolithic design, which is NOT a feature. MS Word has features targeted at lawyers (and useless for everybody else), at accountants, at writers, etc., etc. You don't need most of them, but get all of them anyway. Pluggable modules would have been a much cleaner solution (you are a lawyer? plug in the "Lawyer" module...)
Actually this is one of the things that they were trying to do with COM/OLE/etc. Maybe they'll get there yet but I rather doubt it. It looks like the usual couple of big company problems: (1) too much legacy code to rewrite, and (2) a lot of internal groups with different goals and not all that much desire to work together.
The potential is still there but some of the Linux component platforms may have a better chance simply because the component support will exist before the applications are to bulky to change. Of course there's the eternal question of which component platform is today's favorite...
Good to hear from you. One of the roles I've played as coder geek in several organizations is highly unofficial liason to the writers. Kept getting managers who either didn't want to bother with it or who actually believed that "it's just writing -- they can whip something up at the last minute"... Couldn't always get the writers into planning soon enough, but at least they knew what was coming down.
On the payoff side, several of the best unofficial UI reviewers I've had have been writers. IMHO, they're much more likely to have a feel for how a customer thinks than us coders.
dan
This might work pretty well if the cheat sheet diagram around the input area was built into the PDA. You could even change it for shifts if you use a full screen as in CE machines instead of a silkscreen input area as in Palms.
It would take a bit more vertical space and less horizontal space than Graffiti. This might not be a good tradeoff, since vertical space is more of a premium in the existing PDA footprints.
After 1 1/2 years my graffiti is still mediocre. I suspect that I'd be much faster and with this, but it would take longer to learn and it's very easy to make mistakes quickly.