"I witness the "magic" of things like pipes and clean textual config-files everyday while at the same time I see the problems with more recent approaches."
I think the limitations of technology in the 1970's combined with the Unix philosophy of never using a single integrated program when you can combine many small ones makes things like pipes a necessity. Whether this is a virtue or a sin is a matter of opinion.
Text files are a sophisticated abstraction that require specialized tools called text editors to create. The fact that we've been using these tools for a long time may lead us to forget the abstraction, but it's still there.
"The ideal way to develop something new would be to take the good parts from the old tools and correct the flaws that have shown in practical use and if this means stripping out 3/4 of the "features" then this is a good thing even though marketing might say otherwise."
I agree (although one person's "features" are often another's fundamental requirements). In addition, I think there's more to creating a superior OS then keeping good parts from legacy systems, correcting flaws, and stripping out unneeded features. Some new ideas are required as well.
I can't say I know much about scripting languages, but in my opinion if a language has more than one kind of assignment operator (+=) or uses an iteration operator (++), it has been at least partially derived from 'C'.
When you say high-DPI, I assume you mean high resolution, not small dot pitch?
I've seen this problem maybe once in 10 years, I don't think it's a common problem. I assume you can work around it by lowering the resolution when you run the program in question.
I didn't make any connection between Unix-like and C-like. It is true, however, that I don't find the idea of everything being a file particularly logical or simple. For many devices, it's just a poor abstraction.
Perhaps I see it that way because my original background is in embedded systems where, at least in the old days, there were no mass storage devices and no good reason to slow down and fatten up the system with an abstration that didn't really fit.
Cobol and Fortran are a lot older than Unix and still in use, but I don't consider longevity the measure of quality.
If you don't believe anything has been learned about OS design in the last 30 years then by all means don't pursue any new OS.
Yes, it's also an attempt to optimize developer efforts as well.
It's not always true that only one copy of a library exists on a machine, so you'd still have to perform an audit to figure out which applications used the version in question.
"Actually, if they didn't, they would have to enter pages of hex code, and yes, people really did so"
Perhaps you're confusing "average people" with "average programmers". Average people prior to MS bought computers that didn't even include compilers or source code. It would have been impossible for them to compile.
In a prior post you said "I was there", but you never said where "there" was. Apparently it wasn't earth in the 70's and 80's.
Shared libraries are primarily a form of optimization. The question is whether the costs of the optimization have exceeded the benefits given the current environment of cheap memory and storage.
These days a customer is much more likely complain about configuration problems then memory and storage use.
"I never understood why someone would design a language with a C-like Syntax today."
I do. For all the interest developers have in new technologies, we fundamentally hate change in our day-to-day work. So Java had to at least be hidebound-compatible with C if Sun hoped to see it adopted widely. As a for-profit company, Sun put marketing above other considerations.
I think open source developers are missing some real opportunities in this area. Freed from corporate restraints, why don't they develop brand new OS's and computer languages that are technically superior or easier to learn than the current Unix-like and C-like paradigms? Perhaps they are I'm just not aware of them.
While automatic code generation is a feature that most IDEs have today, it wasn't the original purpose of an IDE.
The idea was to combine editing, compiling, and (eventually) debugging into a single environment. There was a big productivity boost in features like being able to double-click on a compile error and have the IDE open the file for editing with the cursor on the offending line.
Naturally companies tend to emphasize code generation features because they want to convince you that their product will reduce the amount of code you need to write, but you can use an IDE productively for years without using those features.
"Why Microsoft doesn't just embrace the UNIX family and not fight it beats the hell out of me."
You see, there's this idea in business called profit. No smart business would trade the profits of Windows for the profits of Red Hat Linux.
"Take a Linux distribution (or BSD, or Darwin, or whatever), place a Windows GUI on it, port their apps so that anyone can buy Office (profit!), inherit stronger security from the UNIX model, and add classic Windows support with their Virtual PC/Virtual Server technology they bought from Connectix"
It's easy to suggest this, but the devil is in the details. If MS were going to go that far, they might be better off creating a brand new OS with no backward compatiblity that is more secure and powerful than Unix (yes, it's possible, CS progress didn't stop in the 1970's).
"Hear that, Mr. Gates? It is the sound of inevitability..."
Well, If you mean it's inevitable that Linux will pass Windows, I'm not so sure. But if some day Windows applications are not compelling enough (due to merit or as a standard) to prop Windows up, MS could be a Linux vendor very quickly, so there's really no reason for them to rush into it. When that time comes, the real question will be whether there's enough profit in Linux for a company like MS to bother with. Closing down might be a more logical choice under that (speculative) scenario.
I remember reading a mailing from WordPerfect Corporation shortly after Windows 3.0 was released in which the president of the company stated that they really didn't like Windows and didn't really want to port WordPerfect to it, but due to customer demand, they reluctantly decided to do it. This was at a time when WordPerfect was the leading word processor.
When they released their first version for Windows, their reluctance was obvious in the poor design and buggy behavior. This had nothing to do with changes to Windows made for Windows 95 or NT.
So Wordperfect could have:
1. Entered the Windows market much earlier instead of resting on their market share.
2. Avoided antagonizing their potential Windows customers by implying that it wasn't worth their effort to do a port.
3. Fully tested their Windows version so it wouldn't be so buggy.
4. Respond quickly and effectively to whatever bugs were still present.
The one smart thing WordPerfect Corporation did in that era was to sell their product to Novell at an inflated price. Since Novell's management was so anti-MS they were willing to risk a bad investment for the chance to screw MS. Their gamble failed and now they are trying to sue to make up for it.
It's interesting how you believe those who take MS's side are astroturfers but when somebody claims they worked for WordPerfect and makes an anti-MS claim, you buy into it without proof.
Has it occured to you that even if 50% of Slashdotters were MS astroturfers, that the other 50% wouldn't change their minds about MS. I don't think there are massive amounts of MS astroturfers on Slashdot simply because there's no business advantage to MS.
I'm sorry that you feel bad that Slashdot has become only 75% anti-MS instead of the 99% I imagine it used to be. Diversity is the price you pay for success. Perhaps you could start your own site and just delete all the opinions you disagree with.
"I thought the government anti-trust case meant that nobody else had to prove that Microsoft had engaged in such activities."
You thought wrong. Companies can't just duplicate the government case, they have to show how MS's actions actually harmed them. The Finding of Facts from the goverment case can be submitted as evidence, but the judge in the case isn't bound by them.
Seriously, who cared about HTML generation in word processing programs in the 1994-1996 timeframe? Even today, I'll bet that if you surveyed Word customers to find out the top 25 most important features, that HTML generation wouldn't make the list.
Again, the question is not whether there were secret APIs, but rather whether Novell's business was ruined by them being secret. As I've described in other posts, WordPerfect was in trouble long before Novell bought it and the fact that Novell sold it in less than 2 years suggests that little genuine effort was made to reverse WordPerfect's decline.
I wasn't suggesting that they follow the business proposition you described, only that if they were unable to successfully produce a Windows based product with minimal quality they shouldn't have released it.
The business proposition they did follow: "let's dump a crappy version of WordPerfect on Windows users and hope they buy it based on our reputation on other platforms". It didn't work out to well, did it?
As far the suing part, I was talking about WordPerfect Corp. not Novell. Novell's strategy was "Let's buy a Word processor that is rapidly losing market share, sell it in less than two years at a tiny fraction of what we paid for it, and then sue the market leader a decade later for not revealing all their private API's, when we weren't capable of programming the public API's correctly."
Bundling Office suites with PC's was not very common during the period in question so it is unlikely that it had much impact on WordPerfect's fortunes.
To be fair to Corel, WordPerfect was orginally owned by WordPerfect corporation and then sold to Novell. Obviously there wasn't going to be a WordPerfect Corp with the WordPerfect product being sold by Novell. Clearly, the only reason WordPerfect Corp sold it to Novell was because they understood that it was going down hill. By the time Corel bought it at a bargin basement price, the final nail was in the coffin.
Slashdot Mirror
"I witness the "magic" of things like pipes and clean textual config-files everyday while at the same time I see the problems with more recent approaches."
I think the limitations of technology in the 1970's combined with the Unix philosophy of never using a single integrated program when you can combine many small ones makes things like pipes a necessity. Whether this is a virtue or a sin is a matter of opinion.
Text files are a sophisticated abstraction that require specialized tools called text editors to create. The fact that we've been using these tools for a long time may lead us to forget the abstraction, but it's still there.
"The ideal way to develop something new would be to take the good parts from the old tools and correct the flaws that have shown in practical use and if this means stripping out 3/4 of the "features" then this is a good thing even though marketing might say otherwise."
I agree (although one person's "features" are often another's fundamental requirements). In addition, I think there's more to creating a superior OS then keeping good parts from legacy systems, correcting flaws, and stripping out unneeded features. Some new ideas are required as well.
I can't say I know much about scripting languages, but in my opinion if a language has more than one kind of assignment operator (+=) or uses an iteration operator (++), it has been at least partially derived from 'C'.
I don't know if Ada was the first, but it certainly had cross-platform threading before Java was created.
When you say high-DPI, I assume you mean high resolution, not small dot pitch?
I've seen this problem maybe once in 10 years, I don't think it's a common problem. I assume you can work around it by lowering the resolution when you run the program in question.
True, but there's still a trade-off between consistency and flexibility here. I don't see that sort of trade between OO and procedural languages.
I didn't make any connection between Unix-like and C-like. It is true, however, that I don't find the idea of everything being a file particularly logical or simple. For many devices, it's just a poor abstraction.
Perhaps I see it that way because my original background is in embedded systems where, at least in the old days, there were no mass storage devices and no good reason to slow down and fatten up the system with an abstration that didn't really fit.
Cobol and Fortran are a lot older than Unix and still in use, but I don't consider longevity the measure of quality.
If you don't believe anything has been learned about OS design in the last 30 years then by all means don't pursue any new OS.
Yes, it's also an attempt to optimize developer efforts as well.
It's not always true that only one copy of a library exists on a machine, so you'd still have to perform an audit to figure out which applications used the version in question.
"Average people did not compile from source."
"Actually, if they didn't, they would have to enter pages of hex code, and yes, people really did so"
Perhaps you're confusing "average people" with "average programmers". Average people prior to MS bought computers that didn't even include compilers or source code. It would have been impossible for them to compile.
In a prior post you said "I was there", but you never said where "there" was. Apparently it wasn't earth in the 70's and 80's.
Shared libraries are primarily a form of optimization. The question is whether the costs of the optimization have exceeded the benefits given the current environment of cheap memory and storage.
These days a customer is much more likely complain about configuration problems then memory and storage use.
Your assuming a non-constrained environment. Supporting large fonts is not always an option.
When it is an option, you can design a fixed layout that allows for larger fonts and still enjoy a consistent layout.
"I never understood why someone would design a language with a C-like Syntax today."
I do. For all the interest developers have in new technologies, we fundamentally hate change in our day-to-day work. So Java had to at least be hidebound-compatible with C if Sun hoped to see it adopted widely. As a for-profit company, Sun put marketing above other considerations.
I think open source developers are missing some real opportunities in this area. Freed from corporate restraints, why don't they develop brand new OS's and computer languages that are technically superior or easier to learn than the current Unix-like and C-like paradigms? Perhaps they are I'm just not aware of them.
While automatic code generation is a feature that most IDEs have today, it wasn't the original purpose of an IDE.
The idea was to combine editing, compiling, and (eventually) debugging into a single environment. There was a big productivity boost in features like being able to double-click on a compile error and have the IDE open the file for editing with the cursor on the offending line.
Naturally companies tend to emphasize code generation features because they want to convince you that their product will reduce the amount of code you need to write, but you can use an IDE productively for years without using those features.
Joe S. never balances his checkbook.
"fixed-layout dialogs"
You mean dialogs where you actually know ahead of time what the GUI will look like? I hate that. I'd much rather have layout managers surprise me.
"Why Microsoft doesn't just embrace the UNIX family and not fight it beats the hell out of me."
You see, there's this idea in business called profit. No smart business would trade the profits of Windows for the profits of Red Hat Linux.
"Take a Linux distribution (or BSD, or Darwin, or whatever), place a Windows GUI on it, port their apps so that anyone can buy Office (profit!), inherit stronger security from the UNIX model, and add classic Windows support with their Virtual PC/Virtual Server technology they bought from Connectix"
It's easy to suggest this, but the devil is in the details. If MS were going to go that far, they might be better off creating a brand new OS with no backward compatiblity that is more secure and powerful than Unix (yes, it's possible, CS progress didn't stop in the 1970's).
"Hear that, Mr. Gates? It is the sound of inevitability..."
Well, If you mean it's inevitable that Linux will pass Windows, I'm not so sure. But if some day Windows applications are not compelling enough (due to merit or as a standard) to prop Windows up, MS could be a Linux vendor very quickly, so there's really no reason for them to rush into it. When that time comes, the real question will be whether there's enough profit in Linux for a company like MS to bother with. Closing down might be a more logical choice under that (speculative) scenario.
I remember reading a mailing from WordPerfect Corporation shortly after Windows 3.0 was released in which the president of the company stated that they really didn't like Windows and didn't really want to port WordPerfect to it, but due to customer demand, they reluctantly decided to do it. This was at a time when WordPerfect was the leading word processor.
When they released their first version for Windows, their reluctance was obvious in the poor design and buggy behavior. This had nothing to do with changes to Windows made for Windows 95 or NT.
So Wordperfect could have:
1. Entered the Windows market much earlier instead of resting on their market share.
2. Avoided antagonizing their potential Windows customers by implying that it wasn't worth their effort to do a port.
3. Fully tested their Windows version so it wouldn't be so buggy.
4. Respond quickly and effectively to whatever bugs were still present.
The one smart thing WordPerfect Corporation did in that era was to sell their product to Novell at an inflated price. Since Novell's management was so anti-MS they were willing to risk a bad investment for the chance to screw MS. Their gamble failed and now they are trying to sue to make up for it.
It's interesting how you believe those who take MS's side are astroturfers but when somebody claims they worked for WordPerfect and makes an anti-MS claim, you buy into it without proof.
Has it occured to you that even if 50% of Slashdotters were MS astroturfers, that the other 50% wouldn't change their minds about MS. I don't think there are massive amounts of MS astroturfers on Slashdot simply because there's no business advantage to MS.
I'm sorry that you feel bad that Slashdot has become only 75% anti-MS instead of the 99% I imagine it used to be. Diversity is the price you pay for success. Perhaps you could start your own site and just delete all the opinions you disagree with.
"I thought the government anti-trust case meant that nobody else had to prove that Microsoft had engaged in such activities."
You thought wrong. Companies can't just duplicate the government case, they have to show how MS's actions actually harmed them. The Finding of Facts from the goverment case can be submitted as evidence, but the judge in the case isn't bound by them.
Seriously, who cared about HTML generation in word processing programs in the 1994-1996 timeframe? Even today, I'll bet that if you surveyed Word customers to find out the top 25 most important features, that HTML generation wouldn't make the list.
WordPerfect Corp itself was the primary reason that WordPerfect failed.
Again, the question is not whether there were secret APIs, but rather whether Novell's business was ruined by them being secret. As I've described in other posts, WordPerfect was in trouble long before Novell bought it and the fact that Novell sold it in less than 2 years suggests that little genuine effort was made to reverse WordPerfect's decline.
I wasn't suggesting that they follow the business proposition you described, only that if they were unable to successfully produce a Windows based product with minimal quality they shouldn't have released it.
The business proposition they did follow: "let's dump a crappy version of WordPerfect on Windows users and hope they buy it based on our reputation on other platforms". It didn't work out to well, did it?
As far the suing part, I was talking about WordPerfect Corp. not Novell. Novell's strategy was "Let's buy a Word processor that is rapidly losing market share, sell it in less than two years at a tiny fraction of what we paid for it, and then sue the market leader a decade later for not revealing all their private API's, when we weren't capable of programming the public API's correctly."
Yes, that's why Intuit folded. Once MS saw the potential in products like Quicken and Turbo Tax, they blew them away with products like MS Money.
Bundling Office suites with PC's was not very common during the period in question so it is unlikely that it had much impact on WordPerfect's fortunes.
"In my country, if a criminal commits crimes repeatedly, he gets a bigger sentence... why doesn't this seem to apply to cooperations?"
Having an illegal behaving monopoly is a civil matter, not a criminal one, so your question is meaningless in the context of this suit.
To be fair to Corel, WordPerfect was orginally owned by WordPerfect corporation and then sold to Novell. Obviously there wasn't going to be a WordPerfect Corp with the WordPerfect product being sold by Novell. Clearly, the only reason WordPerfect Corp sold it to Novell was because they understood that it was going down hill. By the time Corel bought it at a bargin basement price, the final nail was in the coffin.