> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 28, 2000 9:58 PM > To: [EMAIL PROTECTED] > Subject: RE: C# (was: aspectJ (was Re: [PATCH] build events)) > > To be quite honest, I do. By and large, what I see in C# is C++ with COM > built inside instead of as add-ons with programming conventions, explicit > calls and runtime. That's coming from someone who has written his share of > C/C++, COM, and Java programs.
VB is all COM too. If you used it you know. Most public symptom of VB dependency on COM: COM+ implementation of inheritance got late and that anounced feature was postponed from B6 to the next version. Of course that VB as a control problem. When one starts talking about threads and other low level issues... > That being said, the more interesting saga is the one where Sun first > flirted and the rebuffed standards bodies. This set the stage for > Microsoft's current move - submitting the proposal to ECMA. I am not getting fooled by that submission. I thin that SUN is more open when controlling than M$ when being open. All of Microsoft open technologies are a bate for MS platform dependencies traps: - C# is tied with COM - is that the most portable Object Brocking technology? - SOAP is getting so complex that a complete implementation needs a lot of effort. Instead of holding to simplicity, M$ pushed SOAP to a full marshalling mechanism, ruling a lot of stuff that is infrequent and that could be solved with more basic mechanisms. It got so complex that I would not try to implement a spec compatible tool on my own. And M$ encourages to use SOAP has a marshaling mechanism. (See Visual Studio next version's preview). They expect to have a lot of COM base solutions both on the client and on the server side as the easiest way of dealing with SOAP and having your software compatible with its complex specs. (It backfired a bit when IBM presented a better implementation sooner.) That would also solve DCOM being no match for CORBA and killing simpler stuff like XML-RPC. On the other hand, there is plenty of support from Sun on connecting to stuff implemented in other languages: - JNI; - CORBA; - COM (in their own way); - And they are even talking about SOAP. One can find this technologies challenging.. but I am sure you had your share of problems when using COM instead of these and I am sure the nature of Java it self will save you from some of those troubles. Maybe the platform neutrality of Java screws placing an embeded ActiveX graphical component in an application, but when you can implement those components in a easy way with the language itself... With VB you have no easy way of implementing GUI/DB/other components, but what I see from my Delphi experience - another tool where it is simple to implement (VCL) components in the language it self - is that all the developers prefer native components to ActiveX stuff. When something in another language is used, it is usualy in a way similar to what you can achieve with JNI or CORBA. So, I do not expect to miss ActiveX gadgets now that I am moving to Java. > Microsoft has long preached language neutrality. Sun has preached platform > neutrality. They both are right. > > - Sam Ruby I still thing Sun is being a bit more honest. And I spent many many years working with (a lot of) M$ techonlogy. Have fun, Paulo Gaspar
