Emulation is a perfectly valid way of achieving portability, so it's patently not BS. Anyway, most Java nowadays is using JIT compilation of bytecode into native machine langauge. So a modern JVM is only emulation in the sense that a C++ compiler is.
JITs rock because they get you the performance of native code compilers with the portability of bytecode/intermediate langages. JIT, possibly combined with some features stolen from functional langages are the way of the future.
You're perfectly right in that you can emulate any language using anything else. Therefore what matters using a standard platform that is widely available and efficient. Right now Java fits the bill better than anything else. I may change my opinion if.NET really takes off, but my guess is that it will tumble at the portability hurdle.
Hmmmm.... you might be surprised how hard it is to write a buggy program in Haskell.
There are no pointers. No segfaults, no pointer arithmetic, no array out of bounds.
It's strongly typed, so most bugs just don't compile in the first place.
It's a pure functional language with no side effects, which means that functions are nicely compartmentalised and can't mess with global variables, or indeed affect anything else in the program other than their return value. This is also great for testing.
There are no mutable variables (though you can simulate them with Monads if you like). This avoids a lot of bugs since it encourages you to write in a style where you're not trying to keep track of a load of changing variables.
You implement looping and control constructs with lists and/or recursion, which tends to avoid bugs with boundary conditions. Also leads to some impressively compact code.
You get lots of reusability through polymorphism and first-class functions, which means you're not endlessly rewriting similar code (and invariably forgetting to update one instance...).
Haskell uses Lazy evaluation, which means that things don't get calculated until they are needed. This allows amusing tricks like using infinite sized data structures:
Numbers are arbitrary length integers, so no problem with data type size.
Programs are written as declarations, so it is usually easier to spot logic errors. Check out the Haskell and C implementations of Quicksort for example.
Basically, I reckon that if everyone coded in Haskell or some other functional language, there genuinely would be less coding errors, for quite a lot of concrete reasons as listed above. This goes quite a long way to explaining why the functional languages do so well in contests like the ICFP.
Good point. There is no langauge that "best for everything". If Perl can claim superiority at anything though, it would have to be for its unbeatable code obfuscation possibilities:-)
I think the important areas for a langauge:
-Readability
-Development speed
-Run time performance
-Correctness (i.e. encouraging bug-free code)
-Popularity (availability of skilled coders)
-Portability (availability of platforms)
-Libraries (availability of ready-made toolkits)
-Conceptual fit with problem
Work out what you want for your project, prioritise the above and make your langauge selection on that basis.
I do often use Haskell (the winning language) myself, because it is pretty near the top in all except run-time performance (it's more than fast enough) and popularity (I'm a hobbyist, so don't care what anyone else uses)
Re:ICFP not a programming language comparison
on
ICFP 2001 Contest Results
·
· Score: 3, Interesting
Yeah, I totally agree that you should pick your langauge based on the context. I know enough different languages not to really care which one I use, so it usually comes down to who else will need to maintain the code (Java often wins in this regard....). I can live with 99.999% success rate, though some might regard that as heresy:-)
Interestingly, I *used* to think that pure functional languges were inconvenient, particularly for stuff like IO and user interfaces.
I have now changed my opinion after investigating a concept called "Monads". These are seriously cool, they are an abstract data type that effectively descibes an "operation". They basically allow you to capture procedural/OOP type concepts of state, communication etc. in a purely functional manner.
Techniques like this may be the key to achieving the best of both functional and procedural/OOP worlds. You get all the accuracy and development speed advantages of functional languages, but gain the ability to manipulate state and interact with the world in a procedural style.
Extremely cool, though it's a tricky concept probably best left to computer scientists and the more hardcore coders....
Not an expert, but isn't Forth used for a lot of embedded and instrument control code?
Forth certainly has a lot in common with functional langauges.
Functional/declarative langauges are great where bug-free precision is required because you specify what the results *are* rather than the steps required to produce the result. I'd feel much more comfortable with my mission-critical stuff written in Haskell than C/C++.
We can't do this for general functions at the moment. Problem is caused by the fact that lots of different algorithms produce the same result for all possible input, and are therefore equal functions.
"Calculate (possibly countable infinite) set determined by condition [reg1] on superset [reg2]"
"return [reg1]th element of countable set [reg2] ordered by comparison function [reg3]"
This would be handy for stuff like calculating the set of all primes.
"Calculate maximum of function [reg1] on set [reg2]"
Perhaps the Great Programmer is writing to something a little more powerful than a mere Turing Machine?
My guess is that "Does [reg1] halt on [reg2]" is an one-cycle machine code instruction on His Almighty Box.
Obviously, the registers are cabable of holding arbitrary length lambda expressions. Much more elegant than all this primitive finite state rubbish.
Re:Just marketing, folks, nothing to get exited ab
on
IBM Wants Linux
·
· Score: 2
Probably it's a matter of momentum. A lot of business decisions get based on market potential, which in turn depend on growth rates, which in turn depend on how much attention the market is getting.
Right now, Linux is getting the attention so that's wher the market potential is. IBM could try to push BSD, but they'd face an extra hurdle in the selling process and risk getting stuck in a market below critical mass. So they choose to focus on Linux.
So it's kind of a self-fulfilling prophecy in a way.
Re:So how would IBM do an AIX-Linux switch?
on
IBM Wants Linux
·
· Score: 2
IBM wouldn't want the hassle of their own distro (I share a flat with an IBM employee so I do get a bit of an insider perspective).
Think about it: IBM wants a stable, affordable open platform that it can build upon to offer it's advanced software and services.
There is very little money in selling the OS itself (AIX is pennies compared to the hardware) and a lot of cost involved with keeping the OS updated. IBM have plenty of other projects to put their top developers on.
It's also a big advantage that the OS is *NOT* made by IBM because they can reassure customers about vendor lock-in. This is probably the No.1 selling point they will use when they go head to head with Microsft's.NET platform.
So the sensible route for IBM is to partner with people who do distros for a living, lending their endorsement and technology where appropriate but generally keeping a hands-off approach and concentrate on their core business.
Which seems to me exactly what they are doing.....
Hmmm.... don't think they're being restrictive exactly. Nothing to stop you installing what you like on top of Debian.
They're just choosing an initial distribution based on a ethical/idealistic principle that they believe in. Nothing wrong with that.
Never used Debian myself, but I'm kinda pleased they're around just making the statement. All credit to people who do something good because they believe in it.
Well, when people talk about market share it is usually by revenue, and given the low price of Open Source databases I'm actually surprised it's even as high as 3%.
But 3% of revenue might actually add up to a fairly substantial proportion of installations.
If you haven't tried them already, I would seriously check out the Delphi/Kylix combination. The IDE and the Visual Development tools in particular are IMO a class apart from Visual Studio, and certainly far superior to any of the free tools available. Not to knock the others, but Borland know how to make development tools like nobody else.
Also the fact that you get sub-second compiles for large projects is rather sweet:-)
Code that you produce with the Borland CLX toolkit should be portable across Linux and Windows. Also, the forthcoming iterations of C++ Builder (essentially Delphi for C++) will be Delphi/Kylix compatible as well. For obvious reasons, Borland have always stayed very Microsoft-compatible and support for things like COM objects, creating DLLs and linking with C/C++ etc. is very good.
The fact that Delphi/Kylix use Object Pascal is frequently raised as an objection which I appreciate may be a concern. However, Object Pascal is a very powerful Pascal derivative that is easy to learn and any competent coder should have no trouble making the transition. I find that I code better in Object Pascal if only because the compiler is much more smart at picking up dubious code.
Even if you don't eventually use Kylix, I would strongly suggest downloading the free Open Edition just to give it a test drive. It's quite an experience that may change your views on how development ought to be done.....
Sounds like yet another example of why patents are really *bad* for innovation.
Rhetorical question: If only one company is allowed to play in a particular field just because they got a critical step patented early, then how exactly is this meant to promote a competitive free market?
Age: 23
Career: Strategy Consulting
Place of work: London, UK
Average weekly hours: 55-60
Max weekly hours: 90-100
Salary: Underpaid (£40,000)
Downsides: Highly variable working hours
Benefits: Great variety of work, Learning experience, Travel, All expenses paid, Great CV points, Fun people
Uh, just spotted that isn't possible.
Cos then you've created G(A)->(D,C) which is a universal compressor, and therefore not possible by your usual arguments.
Course, I'm still interested to see if you could create G which works for a percentage X of possible values of A that gets arbitrarily close to 1. My guess is that this is possible, in which case you can still win money off the original bet by ensuring that X>0.02
Of course, if your opponent knew G, they could always choose a value of A that would confound it. But this isn't the case here.
Also, it may be that X increases only very slowly with filesize, so that in order to get X>0.02 you would need a few solar systems worth of storage and CPUs to complete the challenge.
Can anyone prove/disprove any of this?
You know, I reckon it's actually *always* possible to win $5000, no matter what file is generated, providing it is of sufficient length. This is because knowing the file to be compressed *before* you create the decopressor gives you an advantage over the arbitrary random file case.
Furthermore, I reckon I can write a program G that will, when given any input file A of length>=X, will create a decompressor D and compressed file C such that:
D(C) = A
size (D) + size (C) size (A)
Don't know what X is yet, I supspect around 1 meg is fine though.
A picture at boot time getting people excited? Well that's just great.
Linux could be really good if it stopped duplicating "cute" features from elsewhere and started doing something really innovative.
So we've got all this DRI/OpenGL stuff in Linux. Why not use it to build a 3D flyby sequence on startup, an impression of cyberspace at your command. Demo coders have been doing that stuff for years, surely it can't be that hard to knock together?
That, as much as anything else, would cause the windoze mob to actually stop and think "cool... gotta get some of this linux thing. It's got, like, the best startup sequence of any OS anywhere."
Of course, if you don't want to see linux on the desktop and think it should be reserved for elite hackers and sysadmins who actually care what a compiler does, then you can safely ignore this.
Hmmm... don't know why you choose British sexuality laws as a target. It's generally pretty free and easy over here.
Sure, there are some pretty whacky laws on the books but it's not like they get enforced.....
Interesting point about being free to fight the system. Fight in what way? You can shout your viewpoint as loud as you like, but that isn't much use even in a democracy if you are part of a (possibly correct!) minority that is consistenty outvoted.
And if you fight the system in a different way (e.g. Napster, active protests, hacking) you certainly do risk getting put in jail.
Anyway, thanks for the interesting post. Pretty much my view as well that freedom isn't just black and white.
But I think you need to draw a distinction between:
-Hurting a competitor through better/cheaper products
-Hurting a competitor through market power
A little knowledge of economics would be enough to tell you why there is a difference. Suffice it to say, in the first case you're providing a benefit by offering a better deal to consumers and signalling to less efficient competitors that their resources would be best employed elsewhere in the economy.
In the second case, your market power may actually be driving out more efficient competitors, you are building barriers to entry and extracting monopoly rents that may be fine for your shareholders in the short term but are pretty bad news for consumers/the economy as a whole.
My personal take is that antitrust law should never concern itself with the former, but should be reasonably vigilant in the latter case of competitor harm. The success of capitalism is based on competitive markets, not anti-competitive ones.
I haven't done the maths, so any other economists out there should correct me if I'm wrong. But here's the grossly simplified bit of economic theory that I hope can demonstrate this:
Assume:
Two markets (OS and APP)
Company X has a monoply in OS, but competes with many competitors in APP
The OS product is a necessity for all APPs
Now if X combines OS and APP but leaves the individual OS and APP products on the market, it can't get away with charging more that the price of OS plus the competitive price of APP.
However, if X removes the original (non-combined) OS product, it can now charge the monopoly price of OS+APP. Customers will have to buy this, because they can't do anything without OS. All the competitors in APP will be unable to sell at positive price, so will be forced out of the market.
In the repeated case, X will enter new markets, bringing more and more functionality to OS and wiping out competition in each field. You will see the price of OS rising relative to what it would have been without any additions. Net result is that X builds a monopoly in *every* related market by tying *without* any intrinsic advantage (innovation, lower cost) in any of them.
Anyone spot a similarity with the Microsoft case?
Note that all of this doesn't work unless X has monopoly power in the OS market. Without that power, either competitors or consumers can create an alternative (OS+APP) that will prevent monopolisation.
Now for my reccomendation....
If company X wants to combine two products and posesses monopoly power in at least one of them, it may be forced to produce either of the separate products at a discount equal to the economic cost of the non-included product. This should be done on the request of any competitor. Furthermore, it must take all reasonable steps to ensure that competitors have a legal and technological opportunity to create a rival combined product using company X's monopoly product as one component.
This sounds fair to me.... it would remove most of the economic objections to market monopolisation. Sophisticated customers/OEMs would continue to be able to buy and combine products themselves. Less sophisticated customers could gain the convenience of a combined install, but retain choice over competing products. Competitors would be fairly rewarded for the value of the components they had created - if they had a truly better APP, they would be able to market their combination for a higher price than the (OS+APP) combination of company X.
I guess my conclusion is that to retain competition in highy interlinked product markets such as software, it may be optimal to enforce componentisation of products with standard interfaces and then create a separate market in the bundling and distriubution of these core components. This could be done either by the component makers themselves or independant distro companies, but the key point is the *right* to use someone else's components at a fair price in your product. This allows small, specialised companies to compete. It also forces big companies to play fair and adhere to standards.
My prediction is that economic problems such as these will become an increasingly big deal. How we choose to solve them will be an important factor in the levvel of economic development we are able to attain in the 21st century.
But I managed to IP tunnel through spam. Seriously. You rely on a the laws of probability to ensure that a few people reply to the "remove me" link and inadvertently transfer data embedded in the message.
Clueless newbies on AOL become the wiring in your very own highly obfuscated communication link. Kind of interesting from a philosophical viewpoint - people literally becoming part of the machine.
I think that if you came up with a valid proof, people would take you seriously very quickly and you would have no problem getting published.
Having said that, I somehow doubt that anyone who isn't already a fairly academic mathematician will be able to prove this one. It's a famous problem, and you can bet that virtually every simple route to a proof will have been tried already.
Of course, I would be extremely amused if someone with no mathematical background whatsoever were to prove it:-)
Slashdot Mirror
Emulation is a perfectly valid way of achieving portability, so it's patently not BS. Anyway, most Java nowadays is using JIT compilation of bytecode into native machine langauge. So a modern JVM is only emulation in the sense that a C++ compiler is.
.NET really takes off, but my guess is that it will tumble at the portability hurdle.
JITs rock because they get you the performance of native code compilers with the portability of bytecode/intermediate langages. JIT, possibly combined with some features stolen from functional langages are the way of the future.
You're perfectly right in that you can emulate any language using anything else. Therefore what matters using a standard platform that is widely available and efficient. Right now Java fits the bill better than anything else. I may change my opinion if
I think the point is 24/7 - you need the people to be on hand all the time.
Hmmmm.... you might be surprised how hard it is to write a buggy program in Haskell.
There are no pointers. No segfaults, no pointer arithmetic, no array out of bounds.
It's strongly typed, so most bugs just don't compile in the first place.
It's a pure functional language with no side effects, which means that functions are nicely compartmentalised and can't mess with global variables, or indeed affect anything else in the program other than their return value. This is also great for testing.
There are no mutable variables (though you can simulate them with Monads if you like). This avoids a lot of bugs since it encourages you to write in a style where you're not trying to keep track of a load of changing variables.
You implement looping and control constructs with lists and/or recursion, which tends to avoid bugs with boundary conditions. Also leads to some impressively compact code.
You get lots of reusability through polymorphism and first-class functions, which means you're not endlessly rewriting similar code (and invariably forgetting to update one instance...).
Haskell uses Lazy evaluation, which means that things don't get calculated until they are needed. This allows amusing tricks like using infinite sized data structures:
ones = 1 : ones
(defines an infinite list of ones)
or:
numsfrom x = x : numsfrom (x+1)
positiveintegers = numsfrom 0
naturals = numsfrom 1
(all positive integers and naturals)
Numbers are arbitrary length integers, so no problem with data type size.
Programs are written as declarations, so it is usually easier to spot logic errors. Check out the Haskell and C implementations of Quicksort for example.
Basically, I reckon that if everyone coded in Haskell or some other functional language, there genuinely would be less coding errors, for quite a lot of concrete reasons as listed above. This goes quite a long way to explaining why the functional languages do so well in contests like the ICFP.
Good point. There is no langauge that "best for everything". If Perl can claim superiority at anything though, it would have to be for its unbeatable code obfuscation possibilities :-)
I think the important areas for a langauge:
-Readability
-Development speed
-Run time performance
-Correctness (i.e. encouraging bug-free code)
-Popularity (availability of skilled coders)
-Portability (availability of platforms)
-Libraries (availability of ready-made toolkits)
-Conceptual fit with problem
Work out what you want for your project, prioritise the above and make your langauge selection on that basis.
I do often use Haskell (the winning language) myself, because it is pretty near the top in all except run-time performance (it's more than fast enough) and popularity (I'm a hobbyist, so don't care what anyone else uses)
Yeah, I totally agree that you should pick your langauge based on the context. I know enough different languages not to really care which one I use, so it usually comes down to who else will need to maintain the code (Java often wins in this regard....). I can live with 99.999% success rate, though some might regard that as heresy :-)
Interestingly, I *used* to think that pure functional languges were inconvenient, particularly for stuff like IO and user interfaces.
I have now changed my opinion after investigating a concept called "Monads". These are seriously cool, they are an abstract data type that effectively descibes an "operation". They basically allow you to capture procedural/OOP type concepts of state, communication etc. in a purely functional manner.
Techniques like this may be the key to achieving the best of both functional and procedural/OOP worlds. You get all the accuracy and development speed advantages of functional languages, but gain the ability to manipulate state and interact with the world in a procedural style.
Extremely cool, though it's a tricky concept probably best left to computer scientists and the more hardcore coders....
Not an expert, but isn't Forth used for a lot of embedded and instrument control code?
Forth certainly has a lot in common with functional langauges.
Functional/declarative langauges are great where bug-free precision is required because you specify what the results *are* rather than the steps required to produce the result. I'd feel much more comfortable with my mission-critical stuff written in Haskell than C/C++.
Other useful instructions:
"Is function [reg1] equal to function [reg2]"
We can't do this for general functions at the moment. Problem is caused by the fact that lots of different algorithms produce the same result for all possible input, and are therefore equal functions.
"Calculate (possibly countable infinite) set determined by condition [reg1] on superset [reg2]"
"return [reg1]th element of countable set [reg2] ordered by comparison function [reg3]"
This would be handy for stuff like calculating the set of all primes.
"Calculate maximum of function [reg1] on set [reg2]"
Really, really useful.
Perhaps the Great Programmer is writing to something a little more powerful than a mere Turing Machine?
My guess is that "Does [reg1] halt on [reg2]" is an one-cycle machine code instruction on His Almighty Box.
Obviously, the registers are cabable of holding arbitrary length lambda expressions. Much more elegant than all this primitive finite state rubbish.
Probably it's a matter of momentum. A lot of business decisions get based on market potential, which in turn depend on growth rates, which in turn depend on how much attention the market is getting.
Right now, Linux is getting the attention so that's wher the market potential is. IBM could try to push BSD, but they'd face an extra hurdle in the selling process and risk getting stuck in a market below critical mass. So they choose to focus on Linux.
So it's kind of a self-fulfilling prophecy in a way.
IBM wouldn't want the hassle of their own distro (I share a flat with an IBM employee so I do get a bit of an insider perspective).
.NET platform.
Think about it: IBM wants a stable, affordable open platform that it can build upon to offer it's advanced software and services.
There is very little money in selling the OS itself (AIX is pennies compared to the hardware) and a lot of cost involved with keeping the OS updated. IBM have plenty of other projects to put their top developers on.
It's also a big advantage that the OS is *NOT* made by IBM because they can reassure customers about vendor lock-in. This is probably the No.1 selling point they will use when they go head to head with Microsft's
So the sensible route for IBM is to partner with people who do distros for a living, lending their endorsement and technology where appropriate but generally keeping a hands-off approach and concentrate on their core business.
Which seems to me exactly what they are doing.....
Hmmm.... don't think they're being restrictive exactly. Nothing to stop you installing what you like on top of Debian.
They're just choosing an initial distribution based on a ethical/idealistic principle that they believe in. Nothing wrong with that.
Never used Debian myself, but I'm kinda pleased they're around just making the statement. All credit to people who do something good because they believe in it.
Yeah, it's quite a cool game but there's a major bug in the respawning code which kinda sucks.
Well, when people talk about market share it is usually by revenue, and given the low price of Open Source databases I'm actually surprised it's even as high as 3%.
But 3% of revenue might actually add up to a fairly substantial proportion of installations.
If you haven't tried them already, I would seriously check out the Delphi/Kylix combination. The IDE and the Visual Development tools in particular are IMO a class apart from Visual Studio, and certainly far superior to any of the free tools available. Not to knock the others, but Borland know how to make development tools like nobody else.
:-)
Also the fact that you get sub-second compiles for large projects is rather sweet
Code that you produce with the Borland CLX toolkit should be portable across Linux and Windows. Also, the forthcoming iterations of C++ Builder (essentially Delphi for C++) will be Delphi/Kylix compatible as well. For obvious reasons, Borland have always stayed very Microsoft-compatible and support for things like COM objects, creating DLLs and linking with C/C++ etc. is very good.
The fact that Delphi/Kylix use Object Pascal is frequently raised as an objection which I appreciate may be a concern. However, Object Pascal is a very powerful Pascal derivative that is easy to learn and any competent coder should have no trouble making the transition. I find that I code better in Object Pascal if only because the compiler is much more smart at picking up dubious code.
Even if you don't eventually use Kylix, I would strongly suggest downloading the free Open Edition just to give it a test drive. It's quite an experience that may change your views on how development ought to be done.....
Sounds like yet another example of why patents are really *bad* for innovation.
Rhetorical question: If only one company is allowed to play in a particular field just because they got a critical step patented early, then how exactly is this meant to promote a competitive free market?
Age: 23
Career: Strategy Consulting
Place of work: London, UK
Average weekly hours: 55-60
Max weekly hours: 90-100
Salary: Underpaid (£40,000)
Downsides: Highly variable working hours
Benefits: Great variety of work, Learning experience, Travel, All expenses paid, Great CV points, Fun people
I give it 8/10 right now.
Uh, just spotted that isn't possible. Cos then you've created G(A)->(D,C) which is a universal compressor, and therefore not possible by your usual arguments. Course, I'm still interested to see if you could create G which works for a percentage X of possible values of A that gets arbitrarily close to 1. My guess is that this is possible, in which case you can still win money off the original bet by ensuring that X>0.02 Of course, if your opponent knew G, they could always choose a value of A that would confound it. But this isn't the case here. Also, it may be that X increases only very slowly with filesize, so that in order to get X>0.02 you would need a few solar systems worth of storage and CPUs to complete the challenge. Can anyone prove/disprove any of this?
Yeah, I know about <.
:-)
Just that I was submitting in "Plain Old Text" so I would have thought they'd let me get away it.
Slashdot apparently doesn't like open angle brackets.
the condition should read:
size(D) + size(C) "is less than" size (A)
Slightly over-zealous HTML filter, methinks....
You know, I reckon it's actually *always* possible to win $5000, no matter what file is generated, providing it is of sufficient length. This is because knowing the file to be compressed *before* you create the decopressor gives you an advantage over the arbitrary random file case.
Furthermore, I reckon I can write a program G that will, when given any input file A of length>=X, will create a decompressor D and compressed file C such that:
D(C) = A
size (D) + size (C) size (A)
Don't know what X is yet, I supspect around 1 meg is fine though.
Anyone willing to bet either way?
A picture at boot time getting people excited? Well that's just great.
Linux could be really good if it stopped duplicating "cute" features from elsewhere and started doing something really innovative.
So we've got all this DRI/OpenGL stuff in Linux. Why not use it to build a 3D flyby sequence on startup, an impression of cyberspace at your command. Demo coders have been doing that stuff for years, surely it can't be that hard to knock together?
That, as much as anything else, would cause the windoze mob to actually stop and think "cool... gotta get some of this linux thing. It's got, like, the best startup sequence of any OS anywhere."
Of course, if you don't want to see linux on the desktop and think it should be reserved for elite hackers and sysadmins who actually care what a compiler does, then you can safely ignore this.
Hmmm... don't know why you choose British sexuality laws as a target. It's generally pretty free and easy over here.
Sure, there are some pretty whacky laws on the books but it's not like they get enforced.....
Interesting point about being free to fight the system. Fight in what way? You can shout your viewpoint as loud as you like, but that isn't much use even in a democracy if you are part of a (possibly correct!) minority that is consistenty outvoted.
And if you fight the system in a different way (e.g. Napster, active protests, hacking) you certainly do risk getting put in jail.
Anyway, thanks for the interesting post. Pretty much my view as well that freedom isn't just black and white.
Market competition is in general a good thing.
But I think you need to draw a distinction between:
-Hurting a competitor through better/cheaper products
-Hurting a competitor through market power
A little knowledge of economics would be enough to tell you why there is a difference. Suffice it to say, in the first case you're providing a benefit by offering a better deal to consumers and signalling to less efficient competitors that their resources would be best employed elsewhere in the economy.
In the second case, your market power may actually be driving out more efficient competitors, you are building barriers to entry and extracting monopoly rents that may be fine for your shareholders in the short term but are pretty bad news for consumers/the economy as a whole.
My personal take is that antitrust law should never concern itself with the former, but should be reasonably vigilant in the latter case of competitor harm. The success of capitalism is based on competitive markets, not anti-competitive ones.
I haven't done the maths, so any other economists out there should correct me if I'm wrong. But here's the grossly simplified bit of economic theory that I hope can demonstrate this:
Assume:
Two markets (OS and APP)
Company X has a monoply in OS, but competes with many competitors in APP
The OS product is a necessity for all APPs
Now if X combines OS and APP but leaves the individual OS and APP products on the market, it can't get away with charging more that the price of OS plus the competitive price of APP.
However, if X removes the original (non-combined) OS product, it can now charge the monopoly price of OS+APP. Customers will have to buy this, because they can't do anything without OS. All the competitors in APP will be unable to sell at positive price, so will be forced out of the market.
In the repeated case, X will enter new markets, bringing more and more functionality to OS and wiping out competition in each field. You will see the price of OS rising relative to what it would have been without any additions. Net result is that X builds a monopoly in *every* related market by tying *without* any intrinsic advantage (innovation, lower cost) in any of them.
Anyone spot a similarity with the Microsoft case?
Note that all of this doesn't work unless X has monopoly power in the OS market. Without that power, either competitors or consumers can create an alternative (OS+APP) that will prevent monopolisation.
Now for my reccomendation....
If company X wants to combine two products and posesses monopoly power in at least one of them, it may be forced to produce either of the separate products at a discount equal to the economic cost of the non-included product. This should be done on the request of any competitor. Furthermore, it must take all reasonable steps to ensure that competitors have a legal and technological opportunity to create a rival combined product using company X's monopoly product as one component.
This sounds fair to me.... it would remove most of the economic objections to market monopolisation. Sophisticated customers/OEMs would continue to be able to buy and combine products themselves. Less sophisticated customers could gain the convenience of a combined install, but retain choice over competing products. Competitors would be fairly rewarded for the value of the components they had created - if they had a truly better APP, they would be able to market their combination for a higher price than the (OS+APP) combination of company X.
I guess my conclusion is that to retain competition in highy interlinked product markets such as software, it may be optimal to enforce componentisation of products with standard interfaces and then create a separate market in the bundling and distriubution of these core components. This could be done either by the component makers themselves or independant distro companies, but the key point is the *right* to use someone else's components at a fair price in your product. This allows small, specialised companies to compete. It also forces big companies to play fair and adhere to standards.
My prediction is that economic problems such as these will become an increasingly big deal. How we choose to solve them will be an important factor in the levvel of economic development we are able to attain in the 21st century.
But I managed to IP tunnel through spam. Seriously. You rely on a the laws of probability to ensure that a few people reply to the "remove me" link and inadvertently transfer data embedded in the message.
Clueless newbies on AOL become the wiring in your very own highly obfuscated communication link. Kind of interesting from a philosophical viewpoint - people literally becoming part of the machine.
Not very good ping times though....
I think that if you came up with a valid proof, people would take you seriously very quickly and you would have no problem getting published.
:-)
Having said that, I somehow doubt that anyone who isn't already a fairly academic mathematician will be able to prove this one. It's a famous problem, and you can bet that virtually every simple route to a proof will have been tried already.
Of course, I would be extremely amused if someone with no mathematical background whatsoever were to prove it