This is because Java is an single-inheritance, object-oriented programming language, which is great for single inheritance, object-oriented programming. But not for the type of component-oriented programming that EJB land requires. Java just doesn't provide adequate abstraction from the plumbing and as a result, programming EJBs feels like rather an ad hoc process, requiring a whole bunch of junk to be repeated every time the process is started anew.
In this case, a better solution is a better programming language, with better abstractions for the target domain. "Code generation" is simply a band-aid solution (in this case) that automagically gives you a solution. This is ok if you understand what it's doing but dangerous if you don't. Abstraction, not magic, is the key.
Amen. I took particular offense at the first line from a page describing "Code Generation in Action" which states that "Code generation is the technique of using or writing programs that write source code". I guess I'll have to rewrite all my papers by replacing "code generation" with "stuff that the back-end or JIT does".
What really irks me is that this Herrington guy seems to be trying to brand his name along side the misappropriated "code generation" title. Especially considering that this ("code generation") is not a new field and has been called other names in the past.
sdkone gives "Code Generation in Action" a "straight to the trashcan" rating for hubris.
The problem with the JVM is that is was never intended to be a target for any other language apart from Java. So if you want to compile an arbitrary language to the JVM, you'll probably have to make more concessions than if you target the CLR. (Variable parameters for instance.)
But there are still many languages other than Java that can be compiled to the JVM. [My work involves one such language - Component Pascal, not on your list.;) ] But the CLR was designed with multiple language support in mind so you don't need to jump through as many hoops as you do with the JVM.
Just like EJB was repackaged COM/MTS and COM+ was repackaged EJB and CCM was repackaged COM+ and EJB? Bah. You only have to look at some of the recently proposed extensions to the Java language to see the pattern repeating itself again. Each iteration of a technology usually ses significant features from the last - it's this funny thing we call "progress". The similarities are only "striking" if you're totally ignorant of the way the world works.
Cue moderators to mod me down for not bagging.NET...
"Once you get locked into purchasing proprietary software you are forced to upgrade that software, and often the hardware."
Just the sort of totally meaningless crud you can expect from the modern Australian Democrat. Forget vendor lock-in, forget closed standards, and forget lack of extensibility: proprietary software's main problem is... hardware and software upgrades. Brilliant.
If I was an MP, I'd introduce a bill to preference slapping of stupid Democrat MPs whenever they ride a good cause for political mileage.
Ok - now I get what you were originally talking about. Let me start by answering your original question by saying, IANAMSE (I am not a Microsoft employee) but when they say the new explorer will be managed, then they are going to rewrite mostly everything to be managed, and not just use COM interop.
What I thought you were asking is whether they were going to rewrite all (including third party) ActiveX components - which is kind of silly - hence my reply about COM interop.
I'm sick of people saying that languages exist: computers support one language only - binary! And all existing languages have to be mapped to binary!! Blah blah blah...
.NET supports multiple languages - how do I know this? Because there are multiple languages implemented for.NET. QED.
Now if your bitch is that all languages can't be implemented for the CLR then you're almost half right. If your bitch is that all languages can't be implemented for managed execution for the CLR then you are closer to the mark...
Said heap management, caching, etc. couldn't have been implemented in a pre-compiled language?!?
A few points:
1. The.NET runtime JIT-compiles - it does not interpret nor is it designed to be interpreted. Apart from avoiding the hit of the JIT, there is little point in "pre-compiling".
2. In order to have a multi-language, execution environment with complete deterministic garbage collection and the type of security features.NET has, you pretty much need to have a intermediate language that is type safe and verifiable.
3. "Pre-compiling" has a completely different technical meaning than the one you are using.
Err, sorry, I think you're looking for the article titled "Judge Rules Against Microsoft: Massachusetts Shows Microsoft Breached Terms of DOJ Settlement". You can find it about 2-3 years in the future in one of the possible universes that will arise from the universe we find ourselves in today.
I'm guessing those people who modded you up are also from said future. Today's moderators, who should have modded you "-1: Redundant, Overrated, Off-topic, Yet Another Freakin MS Rant", have clearly travelled back in time to mod up other off-topic posts. Anyone who bitched about SCO three years ago can expect a sharp hike in their karma any minute now.
You mention that OOP suffers from similar problems to AOP but the paper you link doesn't describe the half of it. When you said...
Sounds like a disgusting way of trying to legitimise hacks to me. Changing code in ways it wasn't meant to be changed, guaranteed to break lots of things (hence the "horribly easy to accidentally create infinite recursion" reference... no shit Sherlock!)
...you could have easily been talking about implementation inheritance, since it suffers from exactly that problem. Still, implementation inheritance is standard in all modern, popular OO languages because it's so powerful and as long as you try to use it correctly, you probably won't hang yourself.
AOP is another step down that road I think. Objects are powerful, but occasionally confusing - aspects are something along those lines to. There are still problems that need to be worked out before AOP takes off - aspect composition, or feature interaction for one - and I don't think anyone (apart from the evangelists) is really sure if AOP is going to be a big thing.
Btw, I heard a whisper that Gregor Kiczales, the guy credited with pioneering a lot of this stuff, thought that AOP had diverged from what he originally intended. Certainly, the original AOP paper seems to describe something completely different. Make of it what you will...
Slashdot Mirror
This is because Java is an single-inheritance, object-oriented programming language, which is great for single inheritance, object-oriented programming. But not for the type of component-oriented programming that EJB land requires. Java just doesn't provide adequate abstraction from the plumbing and as a result, programming EJBs feels like rather an ad hoc process, requiring a whole bunch of junk to be repeated every time the process is started anew.
In this case, a better solution is a better programming language, with better abstractions for the target domain. "Code generation" is simply a band-aid solution (in this case) that automagically gives you a solution. This is ok if you understand what it's doing but dangerous if you don't. Abstraction, not magic, is the key.
Amen. I took particular offense at the first line from a page describing "Code Generation in Action" which states that "Code generation is the technique of using or writing programs that write source code". I guess I'll have to rewrite all my papers by replacing "code generation" with "stuff that the back-end or JIT does".
What really irks me is that this Herrington guy seems to be trying to brand his name along side the misappropriated "code generation" title. Especially considering that this ("code generation") is not a new field and has been called other names in the past.
sdkone gives "Code Generation in Action" a "straight to the trashcan" rating for hubris.
Or, if number 11 is not satisfied:
12. A software vendor will provide an online forum in which new users can ask questions and experienced users can reply "RTFM".
The problem with the JVM is that is was never intended to be a target for any other language apart from Java. So if you want to compile an arbitrary language to the JVM, you'll probably have to make more concessions than if you target the CLR. (Variable parameters for instance.)
;) ] But the CLR was designed with multiple language support in mind so you don't need to jump through as many hoops as you do with the JVM.
But there are still many languages other than Java that can be compiled to the JVM. [My work involves one such language - Component Pascal, not on your list.
Just like EJB was repackaged COM/MTS and COM+ was repackaged EJB and CCM was repackaged COM+ and EJB? Bah. You only have to look at some of the recently proposed extensions to the Java language to see the pattern repeating itself again. Each iteration of a technology usually ses significant features from the last - it's this funny thing we call "progress". The similarities are only "striking" if you're totally ignorant of the way the world works.
.NET...
Cue moderators to mod me down for not bagging
"Once you get locked into purchasing proprietary software you are forced to upgrade that software, and often the hardware."
Just the sort of totally meaningless crud you can expect from the modern Australian Democrat. Forget vendor lock-in, forget closed standards, and forget lack of extensibility: proprietary software's main problem is... hardware and software upgrades. Brilliant.
If I was an MP, I'd introduce a bill to preference slapping of stupid Democrat MPs whenever they ride a good cause for political mileage.
Ok - now I get what you were originally talking about. Let me start by answering your original question by saying, IANAMSE (I am not a Microsoft employee) but when they say the new explorer will be managed, then they are going to rewrite mostly everything to be managed, and not just use COM interop.
What I thought you were asking is whether they were going to rewrite all (including third party) ActiveX components - which is kind of silly - hence my reply about COM interop.
I'm sick of people saying that languages exist: computers support one language only - binary! And all existing languages have to be mapped to binary!! Blah blah blah...
.NET supports multiple languages - how do I know this? Because there are multiple languages implemented for .NET. QED.
Now if your bitch is that all languages can't be implemented for the CLR then you're almost half right. If your bitch is that all languages can't be implemented for managed execution for the CLR then you are closer to the mark...
Said heap management, caching, etc. couldn't have been implemented in a pre-compiled language?!?
.NET runtime JIT-compiles - it does not interpret nor is it designed to be interpreted. Apart from avoiding the hit of the JIT, there is little point in "pre-compiling".
.NET has, you pretty much need to have a intermediate language that is type safe and verifiable.
A few points:
1. The
2. In order to have a multi-language, execution environment with complete deterministic garbage collection and the type of security features
3. "Pre-compiling" has a completely different technical meaning than the one you are using.
ActiveX controls are COM components and the COM interop stuff in .NET is excellent.
Err, sorry, I think you're looking for the article titled "Judge Rules Against Microsoft: Massachusetts Shows Microsoft Breached Terms of DOJ Settlement". You can find it about 2-3 years in the future in one of the possible universes that will arise from the universe we find ourselves in today.
I'm guessing those people who modded you up are also from said future. Today's moderators, who should have modded you "-1: Redundant, Overrated, Off-topic, Yet Another Freakin MS Rant", have clearly travelled back in time to mod up other off-topic posts. Anyone who bitched about SCO three years ago can expect a sharp hike in their karma any minute now.
Proprietary? When did we start talking about the JVM?
ISO/IEC CLI standard
But then you did call the CLI/.NET a "protocol" so I'm guessing you're not too overstocked in the clue department anyways...
You mention that OOP suffers from similar problems to AOP but the paper you link doesn't describe the half of it. When you said...
...you could have easily been talking about implementation inheritance, since it suffers from exactly that problem. Still, implementation inheritance is standard in all modern, popular OO languages because it's so powerful and as long as you try to use it correctly, you probably won't hang yourself.
Sounds like a disgusting way of trying to legitimise hacks to me. Changing code in ways it wasn't meant to be changed, guaranteed to break lots of things (hence the "horribly easy to accidentally create infinite recursion" reference... no shit Sherlock!)
AOP is another step down that road I think. Objects are powerful, but occasionally confusing - aspects are something along those lines to. There are still problems that need to be worked out before AOP takes off - aspect composition, or feature interaction for one - and I don't think anyone (apart from the evangelists) is really sure if AOP is going to be a big thing.
Btw, I heard a whisper that Gregor Kiczales, the guy credited with pioneering a lot of this stuff, thought that AOP had diverged from what he originally intended. Certainly, the original AOP paper seems to describe something completely different. Make of it what you will...