Isao Tomita (try Diskographia) produced an album "Dawn Chorus" which used these kind of effects. He took the waveforms from various star radio emissions and transposed them into his synth for the various tracks.
Most spooky and impressive is the intro track which gives the album its name. This is a transposed recording of the radio wave noise as the sun rises over the horizon at dawn. The pops, whistles and chirps sound pretty much exactly like a real dawn bird chorus.
The basic problem is that wavelet compression is asymetrical - i.e. it takes a lot longer for images to be compressed than decompressed. This means it has been difficult to promulgate wavelet compression schemes which are dramatically better than say JPEG's which pretty much everybody can generate.
Also, a lot of wavelet researchers are looking for the best wavelet (or should that be tube;-) rather than concentrating on commercialising a particular algorithm/format.
The most exciting thing about Wavelets (and fractals) is the hierarchical information filters that they represent. E.g. its possible to compare images compressed as wavelets very efficiently. The general trend of an image is represented by the large coefficients, and the detail by the small coefficients. There are a couple of projects out there which allow you to search a database of images by roughly sketching what you think an image looks like. The database search refines itself by looking at the high coefficients followed by the smaller coefficients. This has to be pretty much how are brains operate. Very cool stuff.
Fractal compression is actually the same as Wavelet compression, if the data is compressed not on a scanline basis but on a Peano Curve ( a type of fractal).
Free-pascal is a great clone of the Delphi compiler - with a handful of nice extensions.
For those doubters out their, Object Pascal (which is what Delphi and FP are) is virtually interchangeable with C++ and Java. Delphi compiles real quick and produces very tight code - more than can be said for a lot of C++ programs.
There are some great things like properties (concise and orthogonal ways of using get/set methods or data members) which help decouple the implementation, and the in-built meta-class and RTTI is very useful. Constructors are treated like first class methods - so you can easily reinitialise existing objects without having to recreate them.
There are things that suck - I hate having to predeclare all my variables, but otherwise it does things a properly grown up Object based language should.
There are a handful of language extensions which should go into FP:
interfaces interface forwarding (delegation)built-in threading (under consideration) extended RTTI - along the lines of Java reflection.
If these features go in, then we'll have a fast object based, cross-platform language with excellent component development features.
Most artists make very little money out of their recordings. The majority of their serious income comes from fan memorabilia - tee-shirts, calendars, posters etc.
One particularly amusing example of this is Danni Minogue who made an absolute fortune out of her topless calendars.
Oasis were in the same position.
The bottom line as everybody knows is the only losers in this game will be the record labels. But if they're smart (fat chance) they'll be taking a percentage of memorabilia sales - after all they probably bankroll the graphic artists and find the production plants.
The key thing here is, the music is an addictive drug which persuades people to buy tat with the bands logo on it. So why not give the music away anyway.
There is a big mistake with Kylix - attempting to keep the flawed VCL object model. Dev's in Inprise know that it has problems, dev's outside Inprise know it has problems - so why not fix the problems, code to GTK (which is also portable to Windows, BeOS etc) and forget the Window's legacy. C'est la vie - they want to keep their 300k developers - small fry in the big picture.
>i pay for stuff, when its worth it. i can justify software pirating. i wouldnt pay for photoshop, so adobe loses no cash. its an old excuse, sure, but its the truth. Perhaps if you're using it you should send what you think its worth... if not to Adobe, to a free software fund.
But a little bit of theoretical work with a binary system shows that energy can be lost from the system in the form of ripples in Space/Time - our good old fashioned gravity waves.
By analogy with electromagnetism it was then supposed that these waves take the form of discrete packets of energy - gravitons.
So if we presume that dear old gravity and quantum mech can be married at some level, its reasonable to assume that gravitons behave both like waves and particles (I recommend books by Richard Feynman if you want to get a good feel for this - and avoid Hawking like the plague, he can't write and he gets it wrong. Its amazing what a bit of media manipulation can do).
Richard Feynman - the greatest Physicist of the 20th Century.
Showing that the energy flux from a particular system corresponds to the theoretical energy loss via gravitational radiation doesn't prove that the waves exist.
It increases the likelihood that the theoretical predictions are correct, BUT, I believe to really drive the point home we need to observe localised fluctuations in the S/T continuum.
Soft instruction sets ? That's gonna make it really easy for compiler writers - NOT.
If you want to see truly excellent processor technology take a look at the ARM processors. www.arm.com
Very low power, very fast and modular.
For innovation look at the clockless designs they've prototyped - they're really funky - fast and use next to zero power.
They're also Intel's biggest headache - having inherited the rights to the StrongArm they don't know what to do with it. It craps on all their processors and is CHEAP!
10x slower ? Maybe 1.2/1.3 is, but try out the IBM 1.1.8 VM on Linux and Win32, it REALLY flies.
Two years ago I performed some basic benchmarks on the Symantec implementation (and JIT). For tight loops performing repetitive math ops it was approaching C speed. If C == 1 JIT'd Java = 1.7 .
This was a kindof artificial test. My experience is that the JDK in general with a good JIT is about 2.5 times slower, but can approach C/C++ under some circumstances. I find that the IBM implementation often seems to duck into 1.5 sort of territory.
On a nose by nose comparison with C++, Java will often win - purely because you can often implement some types of problem more cleanly in Java.
Where it does fall down is in the AWT libraries (Swing in particular I'm afraid) where some real howlers occur. This of course give Java the impression of being a real dog - WYSIWIG right ?)
If you can find a decent third party lightweight component implementation you'll find that Java is in a position to write Office applications.
BTW, its a great shame IBM don't port to BeOS and Mac:-)
Well, M$ being the cornered animal it will almost certainly be more dangerous than it was before. There's going to be a couple of years before any formal action will be taken against the giant - and in that time it can be even more agressive.
In fact if I was Bill, I would be looking how to divide M$ now and ensure that it can survive by taking over the new market opportunities. Whether we like or not, M$ has some extremely good programmers and perhaps with the proper edict they might start producing compact efficient code:-)
If M$ does get broken up the market is going to be even more frenetic with semi-autonomous groups that no longer have to toe a single party line. This could be real fun.
Perhaps we also have to wonder, if M$ loses big-time, the next monopolists will be Sony and their ilk. Last time I looked, you had to pay them a license in order to write software for their machines...
As the writer of the put, M$ will receive income from selling the put to third parties. The third parties will only exercise the option if M$ stock goes down and in general M$ stock is going up so M$ make a small income from the writing process (somewhere between 1% - 10% of the stock price). A put is the right to sell the stock at a specified price - you'll only exercise that option if the spot price is below the exercise price of the option.
Its also a hedging strategy because in the event of the M$ price going down the put purchasers will be buying stock to sell back to M$ at the put exercise. This creates a rally on the stock and the price starts pushing up again. (Zero arbitrage argument).
The article seems to want to avert a 20/30's style crash, yet his suggested solution is likely to create such a crash. M$ undoubtedly practices 'alternative' accounting procedures, but that's its job. It has to ensure that it acts in the best interests of its shareholders. E.g. what is wrong with issuing puts on its stock ? This provides a good source of revenue for M$ and could act as a good brake during minor price drops. Looks like a hedging strategy to me, and if a large corporation doesn't employ hedging strategies then its shareholders should be worried. The other thing that seems to be ignored, is that the whole financial system works through self-fulfilment. The Mutuals who control a great deal of movement in the stock market have bet their cash on these obviously dodgy stock prices and consequently are unlikely to start divesting in bulk and consequently cause a price crash.
Kind of agree with you on this, but its not wholly true. The size of the corporation often makes a difference. A lot of the early commercial stuff was well designed - small (5 man) teams. There are several reasons why commercial software becomes bloatware: 1. Inability of corporate to take a deep breath and say "Sure you can rewrite it from scratch". 2. Commercial pressure to fix bugs when the original designer(s) has moved on - of course there is no documentation and even if there was, there's no time to peruse it 'cos that bug has to be fixed in 4 hours. 3. Intransigent end users (The pressure to maintain backward compatibility). Most OSS users are pretty flexible with changes in their software. Esp. if they see that its a more elegant solution. They're programmers after all. Most commercial apps are used by people that don't have the patience to rebuild their app and would dearly love to open yesterdays document.
Whilst a lot would appear to depend on the size of the survey, this result isn't particularly suprising. VB has a (relatively) simple to use UI builder which gives immediate results. The closest thing to it is Delphi (why didn't that show up in the results?). Java on the other hand has several UI builder offerings, but nothing really sticks out as being as friendly as VB. The really sad thing is that programmers carry on programming in the language that they start in... which means that we'll have a lot of Java written in VB;-)
I'm kinda confused by the whole thin client thing.
Its possible to buy desktop and laptop machines which have the equivalent of supercomputer processing power. Shortly it will be possible to purchase PDA's with the same amount of power.
Some PDA's now available carry more processing power than a desktop machine I had 5 years ago.
You can buy hard-drives with 22Gb of storage space for under $150.
Browsers suck. You kind of think they're ok until you use a native app doing the same task. Something like IRC is a good case in point. Try using an HTML based IRC client followed by something like Yahoo Messenger (ok its not IRC but similar and is a really NODDY app). The difference is astounding.
Here I am typing into this crummy little text box and marking HTML up by hand, when I could be using a decent HTML word processor. HTML sucks.
And why the hell do people think that XML is some kind of saviour ? Its great as a comms protocol and for marking up data, but it doesn't do anything to solve the problem of creating a really usable UI.
Why doesn't Java work ? Well Java apps are pretty thin if all your UI requirements are on the target machine. But this just doesn't happen. This is exacerbated by browsers not having proper java support as standard - might be slightly better if AOL/Sun get their collective asses into gear and ship the JDK on the AOL CDs.
The thing is, you can say the same for any language. A Java prog. could in principle use just the same elements as the dear old browser, but it sucks doesn't it. It all boils down to Lowest Common Denominator(LCD). Its damn remarkable what people have done with HTML but it doesn't excuse us working with a prehistoric technology.
I think part of the solution is to have a set of common UI controls defined using good old IDL to give language transparency. This would be coupled with a formal mechanism for embedding controls within one another (even if written in different languages). Troll software have gone someway towards this goal with their KOM proposal, and whilst I think the Qt kit is generally very good, it still falls short of the ideal UI toolkit.
The next part of the solution is to define a framework within which the interaction experience can be customized. The original remit of Java and HotJava was to have a completely dynamic browser environment. One in which you could use just plain old HTML if that was all you wanted, but, you could also install extensions to the browser dynamically. Not in the wishy-washy way that applets do it, but true application extensions - things that actually remain installed instead of being loaded every time from the network.
Couple this with proper versioning and a flexible security model (browser sandbox models were far too restrictive) and you start to have the makings of a good solution.
Another part of the puzzle is to continue using some form of connectionless protocol between the client apps and the server - as this would appear to be the only truly scalable solution. There may of course be times when a permanent connection is suitable but those should be few and far between. The connectionless requirement is why the X-term solution doesn't really cut-it. You have to assume that your app may have 10000+ users at any one time.
There has to a realisation that an application's logic should be distributable. That essentially means that you should be able to load balance by choosing either the server or the client for performing compute intensive task. In some cases server side only makes sense, in other client side etc.
Finally, our portable UI toolkit would ideally be scalable, but in reality we have to notice that different form factors have totally different capabilities - and taking the LCD approach is just a cop-out. Classify the types of UI that are possible - Phone, PDA, Sub-Notebook, Desktop, Holodeck - and provide UI's appropriately for all of them. This is why a good decoupling of the UI from the core-logic is essential. Building the UI should be near trivial - but have you noticed how much logic actually goes into making UI's behave sensibly - this really is a fault of the toolkits we use.
I scratched my head when I read this and wondered what all the fuss was about. Its seems to be just another bunch of silliness written by people that don't really understand the underlying technology.
1. Why is it a threat to Java - or any other programming language for that matter ? This is a protocol for passing objects by value (come on CORBA3 - hello RMI:-) and implementing method calling protocols.
2. Using XML in this way is hardly novel. There must be 101 projects out there that are doing exactly the same thing. It would be nice if there was a single mechanism though.
3. "Firewalls don't allow arbitrary ports to be open for the average distributed object protocol" (paraphrased from the MS SOAP site). Well there's a damn good reason for that. It makes your server terribly insecure. Allowing arbitrary method calls to be made over HTTP just expands the problem enormously. This is the distributed object equivalent of MACRO languages. Before widespread use of MACROS we only really had to worry about binary viruses and worms - which were tricky to write but sort of detectable. With the advent of MACROs everywhere the virus problem is ten times worse than it was before - and allowing arbitrary method calls over HTTP is just doing the same thing.
4. Why are CORBA and DCOM complicated ? Well at their core they're pretty simple. They define an interface definition language which is a subset of most common procedural declaration syntaxes. This allows the definition of complex object interactions to be defined without reference to a particular language. However the complexity of CORBA and DCOM comes in the peripheral definitions it was realised had to be made in order to make them useful. i.e. they define a suite of services - Object resolution, Events, Transactions, Security etc, etc, which are non-trivial pieces of software. This is exacerbated by the fact that the OMG hasn't provided reference implementations and that CORBA was interpretable 100 different ways. Object interaction - methinks not.
Anyway I guess the final point is CORBA (and probably DCOM - but its such a hybrid bastard that its hard to tell) started out life as really simple ideas. Probably even simpler than SOAP or any similar projects. The problem is, their actual problem domain is huge, encompassing most of the computing industry and its exactly this sort of half-baked "Oh look we solved all the world's ills" thinking that led to 'products' like COM and the huge shambling mess that is CORBA (read DCOM here too).
The rather strange thing is, by getting something like SOAP ratified as an Open Standard MS probably has the greatest chance of this thing stalling and never seeing the light of day. By the time 20 or 30 companies start squabbling over minor details this will all disappear in a puff of smoke.
Slashdot Mirror
Most spooky and impressive is the intro track which gives the album its name. This is a transposed recording of the radio wave noise as the sun rises over the horizon at dawn. The pops, whistles and chirps sound pretty much exactly like a real dawn bird chorus.
The basic problem is that wavelet compression is asymetrical - i.e. it takes a lot longer for images to be compressed than decompressed. This means it has been difficult to promulgate wavelet compression schemes which are dramatically better than say JPEG's which pretty much everybody can generate.
;-) rather than concentrating on commercialising a particular algorithm/format.
Also, a lot of wavelet researchers are looking for the best wavelet (or should that be tube
The most exciting thing about Wavelets (and fractals) is the hierarchical information filters that they represent. E.g. its possible to compare images compressed as wavelets very efficiently. The general trend of an image is represented by the large coefficients, and the detail by the small coefficients. There are a couple of projects out there which allow you to search a database of images by roughly sketching what you think an image looks like. The database search refines itself by looking at the high coefficients followed by the smaller coefficients. This has to be pretty much how are brains operate. Very cool stuff.
Interesting fact:
Fractal compression is actually the same as Wavelet compression, if the data is compressed not on a scanline basis but on a Peano Curve ( a type of fractal).
Free-pascal is a great clone of the Delphi compiler - with a handful of nice extensions.
For those doubters out their, Object Pascal (which is what Delphi and FP are) is virtually interchangeable with C++ and Java. Delphi compiles real quick and produces very tight code - more than can be said for a lot of C++ programs.
There are some great things like properties (concise and orthogonal ways of using get/set methods or data members) which help decouple the implementation, and the in-built meta-class and RTTI is very useful. Constructors are treated like first class methods - so you can easily reinitialise existing objects without having to recreate them.
There are things that suck - I hate having to predeclare all my variables, but otherwise it does things a properly grown up Object based language should.
There are a handful of language extensions which should go into FP:
interfaces
interface forwarding (delegation)built-in threading (under consideration)
extended RTTI - along the lines of Java reflection.
If these features go in, then we'll have a fast object based, cross-platform language with excellent component development features.
Most artists make very little money out of their recordings. The majority of their serious income comes from fan memorabilia - tee-shirts, calendars, posters etc.
One particularly amusing example of this is Danni Minogue who made an absolute fortune out of her topless calendars.
Oasis were in the same position.
The bottom line as everybody knows is the only losers in this game will be the record labels. But if they're smart (fat chance) they'll be taking a percentage of memorabilia sales - after all they probably bankroll the graphic artists and find the production plants.
The key thing here is, the music is an addictive drug which persuades people to buy tat with the bands logo on it. So why not give the music away anyway.
There is a big mistake with Kylix - attempting to keep the flawed VCL object model. Dev's in Inprise know that it has problems, dev's outside Inprise know it has problems - so why not fix the problems, code to GTK (which is also portable to Windows, BeOS etc) and forget the Window's legacy. C'est la vie - they want to keep their 300k developers - small fry in the big picture.
>i pay for stuff, when its worth it. i can justify software pirating. i wouldnt pay for photoshop, so adobe loses no cash. its an old excuse, sure, but its the truth. Perhaps if you're using it you should send what you think its worth ... if not to Adobe, to a free software fund.
Sure does.
But a little bit of theoretical work with a binary system shows that energy can be lost from the system in the form of ripples in Space/Time - our good old fashioned gravity waves.
By analogy with electromagnetism it was then supposed that these waves take the form of discrete packets of energy - gravitons.
So if we presume that dear old gravity and quantum mech can be married at some level, its reasonable to assume that gravitons behave both like waves and particles (I recommend books by Richard Feynman if you want to get a good feel for this - and avoid Hawking like the plague, he can't write and he gets it wrong. Its amazing what a bit of media manipulation can do).
Richard Feynman - the greatest Physicist of the 20th Century.
It increases the likelihood that the theoretical predictions are correct, BUT, I believe to really drive the point home we need to observe localised fluctuations in the S/T continuum.
Of course that's failed miserably so far
Its good to get excited tho
Soft instruction sets ? That's gonna make it really easy for compiler writers - NOT.
If you want to see truly excellent processor technology take a look at the ARM processors.
www.arm.com
Very low power, very fast and modular.
For innovation look at the clockless designs they've prototyped - they're really funky - fast and use next to zero power.
They're also Intel's biggest headache - having inherited the rights to the StrongArm they don't know what to do with it. It craps on all their processors and is CHEAP!
10x slower ? Maybe 1.2/1.3 is, but try out the IBM 1.1.8 VM on Linux and Win32, it REALLY flies.
:-)
Two years ago I performed some basic benchmarks on the Symantec implementation (and JIT). For tight loops performing repetitive math ops it was approaching C speed. If C == 1 JIT'd Java = 1.7 .
This was a kindof artificial test. My experience is that the JDK in general with a good JIT is about 2.5 times slower, but can approach C/C++ under some circumstances. I find that the IBM implementation often seems to duck into 1.5 sort of territory.
On a nose by nose comparison with C++, Java will often win - purely because you can often implement some types of problem more cleanly in Java.
Where it does fall down is in the AWT libraries (Swing in particular I'm afraid) where some real howlers occur. This of course give Java the impression of being a real dog - WYSIWIG right ?)
If you can find a decent third party lightweight component implementation you'll find that Java is in a position to write Office applications.
BTW, its a great shame IBM don't port to BeOS and Mac
Well, M$ being the cornered animal it will almost certainly be more dangerous than it was before. There's going to be a couple of years before any formal action will be taken against the giant - and in that time it can be even more agressive.
:-)
In fact if I was Bill, I would be looking how to divide M$ now and ensure that it can survive by taking over the new market opportunities. Whether we like or not, M$ has some extremely good programmers and perhaps with the proper edict they might start producing compact efficient code
If M$ does get broken up the market is going to be even more frenetic with semi-autonomous groups that no longer have to toe a single party line. This could be real fun.
Perhaps we also have to wonder, if M$ loses big-time, the next monopolists will be Sony and their ilk. Last time I looked, you had to pay them a license in order to write software for their machines...
This isn't true.
As the writer of the put, M$ will receive income from selling the put to third parties. The third parties will only exercise the option if M$ stock goes down and in general M$ stock is going up so M$ make a small income from the writing process (somewhere between 1% - 10% of the stock price). A put is the right to sell the stock at a specified price - you'll only exercise that option if the spot price is below the exercise price of the option.
Its also a hedging strategy because in the event of the M$ price going down the put purchasers will be buying stock to sell back to M$ at the put exercise. This creates a rally on the stock and the price starts pushing up again. (Zero arbitrage argument).
The article seems to want to avert a 20/30's style crash, yet his suggested solution is likely to create such a crash. M$ undoubtedly practices 'alternative' accounting procedures, but that's its job. It has to ensure that it acts in the best interests of its shareholders. E.g. what is wrong with issuing puts on its stock ? This provides a good source of revenue for M$ and could act as a good brake during minor price drops. Looks like a hedging strategy to me, and if a large corporation doesn't employ hedging strategies then its shareholders should be worried. The other thing that seems to be ignored, is that the whole financial system works through self-fulfilment. The Mutuals who control a great deal of movement in the stock market have bet their cash on these obviously dodgy stock prices and consequently are unlikely to start divesting in bulk and consequently cause a price crash.
Kind of agree with you on this, but its not wholly true. The size of the corporation often makes a difference. A lot of the early commercial stuff was well designed - small (5 man) teams. There are several reasons why commercial software becomes bloatware: 1. Inability of corporate to take a deep breath and say "Sure you can rewrite it from scratch". 2. Commercial pressure to fix bugs when the original designer(s) has moved on - of course there is no documentation and even if there was, there's no time to peruse it 'cos that bug has to be fixed in 4 hours. 3. Intransigent end users (The pressure to maintain backward compatibility). Most OSS users are pretty flexible with changes in their software. Esp. if they see that its a more elegant solution. They're programmers after all. Most commercial apps are used by people that don't have the patience to rebuild their app and would dearly love to open yesterdays document.
Whilst a lot would appear to depend on the size of the survey, this result isn't particularly suprising. VB has a (relatively) simple to use UI builder which gives immediate results. The closest thing to it is Delphi (why didn't that show up in the results?). Java on the other hand has several UI builder offerings, but nothing really sticks out as being as friendly as VB. The really sad thing is that programmers carry on programming in the language that they start in ... which means that we'll have a lot of Java written in VB ;-)
I'm kinda confused by the whole thin client thing.
:-)
Its possible to buy desktop and laptop machines which have the equivalent of supercomputer processing power. Shortly it will be possible to purchase PDA's with the same amount of power.
Some PDA's now available carry more processing power than a desktop machine I had 5 years ago.
You can buy hard-drives with 22Gb of storage space for under $150.
Browsers suck. You kind of think they're ok until you use a native app doing the same task. Something like IRC is a good case in point. Try using an HTML based IRC client followed by something like Yahoo Messenger (ok its not IRC but similar and is a really NODDY app). The difference is astounding.
Here I am typing into this crummy little text box and marking HTML up by hand, when I could be using a decent HTML word processor. HTML sucks.
And why the hell do people think that XML is some kind of saviour ? Its great as a comms protocol and for marking up data, but it doesn't do anything to solve the problem of creating a really usable UI.
Why doesn't Java work ? Well Java apps are pretty thin if all your UI requirements are on the target machine. But this just doesn't happen. This is exacerbated by browsers not having proper java support as standard - might be slightly better if AOL/Sun get their collective asses into gear and ship the JDK on the AOL CDs.
The thing is, you can say the same for any language. A Java prog. could in principle use just the same elements as the dear old browser, but it sucks doesn't it. It all boils down to Lowest Common Denominator(LCD). Its damn remarkable what people have done with HTML but it doesn't excuse us working with a prehistoric technology.
I think part of the solution is to have a set of common UI controls defined using good old IDL to give language transparency. This would be coupled with a formal mechanism for embedding controls within one another (even if written in different languages). Troll software have gone someway towards this goal with their KOM proposal, and whilst I think the Qt kit is generally very good, it still falls short of the ideal UI toolkit.
The next part of the solution is to define a framework within which the interaction experience can be customized. The original remit of Java and HotJava was to have a completely dynamic browser environment. One in which you could use just plain old HTML if that was all you wanted, but, you could also install extensions to the browser dynamically. Not in the wishy-washy way that applets do it, but true application extensions - things that actually remain installed instead of being loaded every time from the network.
Couple this with proper versioning and a flexible security model (browser sandbox models were far too restrictive) and you start to have the makings of a good solution.
Another part of the puzzle is to continue using some form of connectionless protocol between the client apps and the server - as this would appear to be the only truly scalable solution. There may of course be times when a permanent connection is suitable but those should be few and far between. The connectionless requirement is why the X-term solution doesn't really cut-it. You have to assume that your app may have 10000+ users at any one time.
There has to a realisation that an application's logic should be distributable. That essentially means that you should be able to load balance by choosing either the server or the client for performing compute intensive task. In some cases server side only makes sense, in other client side etc.
Finally, our portable UI toolkit would ideally be scalable, but in reality we have to notice that different form factors have totally different capabilities - and taking the LCD approach is just a cop-out. Classify the types of UI that are possible - Phone, PDA, Sub-Notebook, Desktop, Holodeck - and provide UI's appropriately for all of them. This is why a good decoupling of the UI from the core-logic is essential. Building the UI should be near trivial - but have you noticed how much logic actually goes into making UI's behave sensibly - this really is a fault of the toolkits we use.
There's my tuppence halfpenny
I scratched my head when I read this and wondered what all the fuss was about. Its seems to be just another bunch of silliness written by people that don't really understand the underlying technology.
:-) and implementing method calling protocols.
1. Why is it a threat to Java - or any other programming language for that matter ? This is a protocol for passing objects by value (come on CORBA3 - hello RMI
2. Using XML in this way is hardly novel. There must be 101 projects out there that are doing exactly the same thing. It would be nice if there was a single mechanism though.
3. "Firewalls don't allow arbitrary ports to be open for the average distributed object protocol" (paraphrased from the MS SOAP site). Well there's a damn good reason for that. It makes your server terribly insecure. Allowing arbitrary method calls to be made over HTTP just expands the problem enormously. This is the distributed object equivalent of MACRO languages. Before widespread use of MACROS we only really had to worry about binary viruses and worms - which were tricky to write but sort of detectable. With the advent of MACROs everywhere the virus problem is ten times worse than it was before - and allowing arbitrary method calls over HTTP is just doing the same thing.
4. Why are CORBA and DCOM complicated ? Well at their core they're pretty simple. They define an interface definition language which is a subset of most common procedural declaration syntaxes. This allows the definition of complex object interactions to be defined without reference to a particular language. However the complexity of CORBA and DCOM comes in the peripheral definitions it was realised had to be made in order to make them useful. i.e. they define a suite of services - Object resolution, Events, Transactions, Security etc, etc, which are non-trivial pieces of software. This is exacerbated by the fact that the OMG hasn't provided reference implementations and that CORBA was interpretable 100 different ways. Object interaction - methinks not.
Anyway I guess the final point is CORBA (and probably DCOM - but its such a hybrid bastard that its hard to tell) started out life as really simple ideas. Probably even simpler than SOAP or any similar projects. The problem is, their actual problem domain is huge, encompassing most of the computing industry and its exactly this sort of half-baked "Oh look we solved all the world's ills" thinking that led to 'products' like COM and the huge shambling mess that is CORBA (read DCOM here too).
The rather strange thing is, by getting something like SOAP ratified as an Open Standard MS probably has the greatest chance of this thing stalling and never seeing the light of day. By the time 20 or 30 companies start squabbling over minor details this will all disappear in a puff of smoke.